2016 December was the worst month of my life. I had a break-up, had physically assaulted by my father for being a transgender woman and lost my job. All of them happened in the same two month period. I had the deepest kind of depression I’ve ever had. Also, psychosomatic pain accompanied all of this.

For the first two weeks after the attack, I did not escape from my bed. As a depressed person, I was used to suicidal thoughts in my mind, but I don’t remember a time when I was closer than this. Being a woman is hard, being a transgender woman is too, and being all of these and having dreams is more difficult.

Many of you maybe know me from the accepted RFC which I proposed or my PHP book published in Turkish or designing of the new CakePHP bake interface in version 3.1. Sometimes I am very proud of things I made but other times I can find myself sunk in the impostor syndrome.

I applied circa 120 jobs since I quit my job in September 2016, and in this period none of them returned except some invitations to job interviews. One day I was invited to a two-day job trial in Berlin, an all male department and witnessed that they were checking Facebook profiles of woman candidates and making fun of their profile pictures. I was used to the gender bias in office, being yelled for things that male employees were welcomed with compassion, but that was the most extreme case. My father invited me to work with him in the family business, but take heart from my unemployment, for harassing and humiliating and at the end physically attacking.

I was miserable at all, procrastinating, checking only the Facebook and doing nothing. I lost keeping track of hours and days. I lost my appetite; I felt useless and worthless.

I was doing nothing. Some days I was drinking alcohol and getting drunk and feel embarrassed. I was writing whining posts to Facebook and felt the pity in the people’s responses. Worse than that I was wallowing in self-pity. But one day I found out something different. I could continue to live like this and stay ruined every day. Nothing was changing. So, I thought, if nothing changes, and my negative inner voice tells me that nothing is going change with no matter I do, I can do something different without expecting anything. That day, I washed dishes, took an appointment with my therapist, and accepted some guests from the CouchSurfing to force myself to clean the whole house. I was still procrastinating and feeling embarrassed because of procrastination in the Facebook. When I talked about this with my therapist, she told me that it was completely normal.

I asked, “How?”

She said that the procrastination was our brain’s coping mechanism to deal with hard to cope situations. So I understand that I was expecting many things from myself, be perfect, don’t be emotional, be social, fulfil your life, etc. And I decided to take it easy on myself. This video also helped a lot to understand it.

I deleted my facebook account. Not deactivated, but deleted. I was uncomfortable with the idea of myself as a sellable data mining asset. I didn’t like to be alone at home crying, without any message or phone call, but my friend list bloated with 250 people. If someone cares about me, can quickly send me a “How are you?” message. But you cannot expect that effort from the most of your Facebook friends. I was also uncomfortable with all that stupid news, lies, scandals, Donald Trump, Brexit, bombings in Europe, immigration crisis and all of the nonsense fanaticism. Sharing something about some topic you care is doing nothing and deluding yourself that you are doing something tactile, but instead of this, you are just making yourself feel comfortable. One paragraph or 140 character limit of digestible bites and trying to be satisfied with those facebook or twitter posts without any well-thought-out idea or research aiming to create the most impact concludes to extreme trolling. So I was tired of it. Only one week passed, but I feel much better.

I restarted to my research about object oriented programming. I read about physical, philosophical, language meanings of what was an “object”. Last year I was working in a video on demand project with no documentation and code commenting (because my supervisor believed that readable code does not have comments –I don’t agree at all–) with an excellent object oriented language called Haxe that compiles to Javascript to generate React components. I even write objective-C and Android code in Java for our Cordova plugins but no PHP code at all other than my toy projects. We had classes with 5-6 ancestors that required an annoying struggle to find a method’s implementation. (Alt-Enter for JIdea) I was questioning practices and methodologies, but no one other than me seem bothered. Remember the Berlin company douche-bags who were stalking the women candidates Facebook profile pictures? They were using Angular 1.something with SWIG (Some Javascript counterpart of TWIG) code that generates a god controller in Javascript wrapped with HTML, SQL and CSS code. That was the most intense spaghetti practice I’ve ever seen in my life. What were all of those developers in a million dollar multinational companies thinking? How they were this successful and I was feeling non-perfect all the time and have to memorise this book, to be hired? Most of the technology companies and their codebase concede humanity, compassion to their developers and future users to achieve the fastest delivery of the product.

In some job interviews, they ask me what I expect from their company. I tell them that I expect politeness, people talking and helping each other and say hello and good-bye during the day. Why do you rent this office and hiring all of the employees to work together in same space instead of outsourcing all of your IT department with different freelancers based in various countries all around the world? I don’t think most of the HR or IT professionals thought on it.

While I was researching about object oriented programming, I wanted to dig deeper from programming to maths and from there philosophy. What was an object? What was a thing? Dictionaries tell that everything other than our thinking mind is an object, an input for our thought mechanism. What is thinking? How do we think? My head was full of those kind questions. How we distinguish objects? What separates objects or things (“the thing” is an unnamed object) from the world that surrounds them? In that rabbit hole, I found out that the reality is not perfect. In a perfect world 1/n never becomes 0, when n goes to infinity. In real life it does. The perfection deludes us that we are never going to achieve our goals or things we want to obtain and there always be a gap. Remember the Xenon’s paradox? He proved that the arrow never reaches the target, dividing the distance in two to infinity. However, in real life, we arrive a point that can’t be divisible anymore. So there is no dividing to infinity. The infinity tells us that there is an infinitesimal thing somewhere, but we don’t know where. Infinite is nothing, other than our uncertainty and inner insecurities. So the objects and the space around them is finite and exist. No matter how much we try to measure, we cannot know exactly its position with a zero error rate, but we can know the range of its boundaries. If this sounds incomprehensible, think that you can never touch something with your finger. The atoms around the ends of your finger and the object you touch will repel each other. There always be some space between your fingers and the object.

I know I rambled a lot in this article, but I think becoming aware of the imperfect word was the biggest gift of December 2016. There are bad things and there always going to be, instead of being depressed and losing my faith to everything, I embrace them, try to understand the imperfection, giving up trying to be perfect and do whatever I can, without expecting anything more than enjoying the exact moment.

And yes, this is the 25th article.

So I had an idea what I wanted to write about; however, I have the dubious honor of being #24 in the 24 days.  This means I had the chance to read most all of the entries before I sat down to write mine, and suddenly, my original topic didn’t seem quite so poignant, and a few of the articles have struck home with me.

Looking Back

Quite a few of the authors this year have written about the crazy year that they had.  I am no exception.  During this year, I left the previous company that I had founded with some amazing people, and my wife and I created our own company, dedicated to running tech conferences for a living.  While I still find myself writing a lot of code to make things happen, my primary focus is the education of programmers and creating amazing experiences to bind us together as a community.

Originally this was going to be the centerpiece of my article.  But it’s a funny thing when you are a small business owner, especially one who is running a conference … a majority of your time is spent doing marketing.  Marketing, in general, is a tough job, and I respect those that focus on it. Targeting developers is even worse as we are some of the worst skeptics and trained to be critical of everything.

But the one thing that this position has done is opened my eyes to a looming problem that lies before us all in the PHP community.

Introspection

As I was reading the articles posted here so far, I was especially struck by 3 of them that all revolved around the same theme.  Lorna in her article talked about the contempt that some people in the greater webtech community have for PHP, but at one point stated:

We must spread the word beyond the boundaries of our own communities.

Then I was reading the excellent article from Davey about how PHP is Dead — (spoiler: it isn’t).  The meat of the article is about how we are the glue language, we pick up various technologies and stick them together with a bit of PHP code.  We run 80% of the web and need to become shepherds of it, driving adoption of the best standards going forward.  But in the midst of that he made the statement:

We must get out into the wider technical community and spread our knowledge.

Finally, I found myself deep into Michael’s article about working together.  A wonderful discussion of the state of the greater community, how it fragmented into sub-communities, and how people are striving to break those walls down and bridge the communities together.  It’s truly a beautiful story that PHP has been going through, as Michael put it:

I see more and more new faces at conferences each year, both speaking and attending, at generalised PHP conferences and these people are often people who have been to Symfony or Drupal or WordPress conferences before, and just beginning to reach out to the wider PHP community.

But that’s where everything starts to collide in my head.  The intersection of the amazing community we have, the widening of the community, and yes the running of conferences, all starts to swirl together.  Suddenly I realize that I’m too focused in at that moment, and I pull out to see that this beautiful pattern of light, is surrounded by a sea of darkness.

Looking Forward

What is this sea of darkness?  We are encouraging people to reach out beyond the realm of their sub-community and to connect with the other PHP communities.  We are urging the greater PHP community to reach out to the other programming communities and share knowledge.  But there’s a huge gap missing.

The rest of the PHP developers.

You see, PHP runs 82% of the web.  Even with a significant portion of that being WordPress (about 27%), and smaller pieces of it the other main applications such as Drupal or Magneto … that still leaves a significant number of websites out there; that are some variation of custom code.  Plus a substantial portion of those Drupal/WordPress/Magento sites have custom code written into them as well.

What does that mean?  Do you see it yet?  Where are all these developers?

There have been estimates thrown out by companies that care to try to crunch the numbers that there are 5 million PHP developers in the world.  Let’s even make an assumption that this is grossly exaggerated and that there are only 1 million PHP developers.  That sounds certainly reasonable, doesn’t it?  Well according to Facebook, there are 20 million people interested in PHP.

But regardless of whether you want to think 1, 5, or 20 million … if that’s the case — where are they?  Dedicated PHP conferences at best pull 800 attendees (most in the 200 range instead).  Drupal and WordPress, having a wider appeal to non-developers as well can get into the 4,000 attendee range, though closer to that 800 number are typically programmers.  Even with 100 conferences across the globe a year and assuming people only attend on average a conference every other year.  That still only puts the count at somewhere in the 100k range.

Granted, that’s just conferences, but other measures of the community are similar. On php.ug there are ~260 user groups listed, each with between 20-2000 members. The leading PHP group on Facebook has 141k members.  The biggest PHP Developer Group on LinkedIn surprisingly also has 141k members. There are just over 45k people on the PHP sub-Reddit, and php[architect] magazine just has a few thousand regular readers.

The fact is that there is a significant number of people missing.  Who are these people?  Primarily they are the lone developers or members of a small team.  They are the 9-to-5 day job coders, who got a position out of college that just happened to be in PHP.  They shrugged, it’s just like any other programming language, and they started doing their job.

These people, are the ones that can benefit from being a part of the community the most, and these are the people who it is the hardest to reach — because there are not connected, even tangentially to us.

Summary

So while Michael is telling us to break down the walls, and Lorna + Davey are telling us to reach outside of the PHP community … I’m going to say that we need to be finding the “lost community members.”  We need to focus on the search for those other 4 million PHP programmers out there who aren’t a part of the community.  We need to connect to them, let them know that there is a support network for them and that they are welcome to join us.

We need to find our missing brethren, so that our community can be complete, and that we can all learn from each other as we continue to build upon the strong foundations that the history of PHP has provided us.

I am grateful to have had the opportunity to manage teams for several years. Moving from being a full-time engineer to a management position is something that many people have gone through and can say is not easy.

A week ago in a conversation with a coworker, we talked about Leadership and how I learned to do what I do. That left me thinking (a lot) on this bumpy trip. I want to share some tips/ideas/bullet points or whatever you want to call it about this journey on becoming a manager (and trying to become a better leader for my team).

Professional / Personal Growth

Help people to grow and change. Sometimes is difficult for some people to have a clear vision of what they want from their job. You have to actively help your team to think about it and put a plan in place (1:1 are very important on this matter).

Helping engineers to grow is not just sending them to training. You can give them new challenges and challenging assignments that will put them outside their comfort zone. It’s important to provide a safe place where they can fail and learn.

Another way to help them in their professional growth is to let them select what project they work on. In the last 6 months, we changed teams twice and gave those teams the chance to pick what they were going to work and the result was (and is) amazing. Engineers learned about new technologies and got deep knowledge of different parts of the business.

One of the most satisfying things about being a manager is to see people grow individually and collectively.

Learning / Teaching

Everybody in your team should be a mentor and should feel confortable teaching and helping other people. As a leader you should be the number one sponsor of this behaviour and this activity should be part of the culture of the team.

The other side of the story is to create an environment were learning / teaching happen organically. In our case we have 2 meetings with very different purposes:

• We conduct a bi-weekly, 1hr, “Engineering Meeting” for all engineers in our department (+ guests). This is a structured meeting with a predefined agenda with the purpose to spread knowledge or have an open discussion about big themes, for example, arquitectural changes, new technologies, performance improvements, business processes, etc.
• Then we held a non-mandatory, 30 minutes, twice a week, first time in the morning, unstructured “Engineering chats”. The idea of this is to discuss issues related to the current sprint, for example blockers, software design, tests, etc.

Check Cal Evan’s book “Creating a Brown Bag Lunch Program”, it will give you a good starting point to put your team in a Continuous Leaning cycle.

1:1 & continuous feedback

Have regular 1:1 meetings with your direct reports. The best way of doing it is to schedule a recurring meeting in your calendar (at least 30 minutes).
Take notes and get prepared (I use Evernote to track all my 1:1s, read the last meeting notes so you can follow up).
Give and get feedback on yourself. Giving feedback is easier that receiving it but, if you ask for it every time it will feel natural and your team will be confident to give you sincere feedback. Ask for feedback from other team members too. It’s a good moment to talk about their relationship with others and how teams are working/performing. Ask your direct report if there is anything that you can help them and how.

Positive attitude

As a leader, your attitude will shape how people feel about the organization. Be confident even in difficult situations. Stay calm and positive. Just think about it, the mood of your team is a faithful reflection of the attitude of its leader. Be passionate, positive but honest, don’t fake it either.

Delegate

Delegating helps you to focus on what is required for your leadership role, it’s not easy but it’s something that you need to master to became a successful leader. It’s important to understand that you are not delegating tasks because you don’t have time to do them. You are delegating because you really accept that there are people in your team more capable than you to perform those tasks.

Delegating implies accepting that things can be done differently than one would do.

Remember to build a team with people smarter than you.

Inspire (don’t instruct)

Last but not least, always inspire your team, even inspire other engineering teams. Inspiring engineers is a full-time job and it’s not easy. Give your team a vision and provide them a map. Show them the path, be sure that they understand the why they will handle the how.

Conclusion

Management is hard but leading a team is harder, however leadership skills can be learned. Leaders are not a different from others, they are people who were given the opportunity to lead.

I hope this tips can help you to became a better Leader.

Making friends

The year is going to the end and I’m stumbling with some thoughts of the last year.There was a lot i learned for myself. A lot i learned from the community.But there’s also some new contacts and friendships i made. For example i met my new girlfriend Sarah who makes me smile every single morning when i wake up.

PHPMap

I started a new project called PHPMap. It’s kinda like my old project Laramap (which isn’t online anymore). It is an interactive map for PHP-Developers around the world. I got a lot of feedback over twitter, slack, email and in person. One day I walked down a street in Hamburg (Germany) on my way to a meeting. I got touched on my shoulder and I got asked if I were “fwartner”, the creator of PHPMap. I said “yes” and got invited later this day to a beer. It was really funny because I never thought that my projects would make this ever happen. But it happened.

PHPMap is built on Laravel 5.3 with it’s latest features such as notifications, mailables and the oauth2 server. I started working on PHPMap when Laravel 5.3 was in development. When it officially came out, I made some changes to the codebase of PHPMap to have it exactly like I would have any other project built on L5.3.

It was a huge learning process for me. Every new version brings new features. But this one was special. I got mentioned in a lot of tweets regarding to Laravel 5.3 because of my project and was able to help a lot of people with the latest features when they had any questions.

Canceling my job

But there were also some frustrating parts of the year. I canceled my job as a freelancer. Freelancing was cool. It probably is still cool. But for me it was the right time to breakthrough. I needed a new adventure! I was trying to get a new one. I had so many interviews this year. Nothing. The words I ever heard were “We’re sorry but the position is already taken…” But nevermind. One day I will find a new job!

A new journey with SaaS

While looking for a new job, I’m also looking for ideas to run a SaaS-Business. SaaS is becoming more and more popular and grows every single day. So why not get my own pieceof the SaaS-Cake and start a new business?! Well.. I have no idea what I should start with.. I have no idea, what kind of product I should work on. There are so many great tools on the internet.. So many ideas I also have.. But I don’t want to have this companies as my competitors.

But then one of my friends came along with an idea! Let’s create a tool for social-mediamarketers.. (More will follow very soon on Twitter.. ^^)

Conclusion

This was just a small part of my year in review.. The most important lane is still in front of me.. The Family on christmas. I wish you all the best for christmas and a happy new year!

When Andreas asked me if I was interested in writing for 24 Days in December, I took a few days to get back to him because I was caught up in organising a slightly different community event: the first ever Swiss Trans*Code hackday. Getting this up and running has been the high point of my year and I thought I would write about why.

What is Trans*Code?

Trans*Code is a series of hack events started in the UK in 2015, to draw attention to issues that affect the transgender and nonbinary community, and to come up with solutions and opportunities together. (Nonbinary people are those who — like me — have genders that fall outside the male/female binary.) Cisgender allies are welcome to participate, as are designers, ideators, programmers and non-programmers.

There are a few reasons why a hackday for trans people is important. First of all, the trans community suffers from much higher than average unemployment and homelessness, as well as health problems and poverty, due to discrimination. There is more information about this on the page of Trans*H4CK, the American inspiration for Trans*Code. Welcoming people in this situation into tech, and helping them develop technical skills, does something concrete to improve their prospects.

Secondly, of course, the projects people hack on during these events are things that the trans community wants and needs. Past projects include a voice-training web app, a trans clothing exchange, and a mobile app for Twilight People, a project about trans* people of faith.

For me, possibly the most important aspect of Trans*Code is the community building it aims for. As an immigrant to Switzerland, where I speak the language but not confidently, it took me a while to find friends — and it’s taken me till this year to really start making trans connections, which I’ve really missed. When you’re in a minority group, it’s a wonderful and very necessary feeling to be around people who share your experiences. (Even though my favourite thing about the trans community is that we are all so very different.)

Organising my very first event

I’d seen tweets about Trans*Code since its beginning, but there was no way I could attend one in the UK. When I met Naomi Ceder, one of the cofounders, at PyCon this year, I asked her if it would be possible to start Trans*Code Switzerland, and then immediately sort of regretted it! There was no way I could arrange an event like this myself, right? It would involve getting sponsorship, talking to vendors for food and drink, doing lots of advertising and somehow trying to drum up word of mouth. All at once I remembered how disorganised and introverted I can be.

In an amazing stroke of luck, however, Naomi had also been approached by another Zürich-based programmer about holding Trans*Code events over here. She put me and Arielle Albon in touch and we quickly decided we could work together.

Setting up our website, a Twitter account and ticket booking for the event was easy. My employer, Liip, sponsored the venue (thank you!). Other tasks were harder, as I’d expected: when it was time to actually tweet and publicise the hackday, I suddenly became incredibly shy. It was a huge help to have a co-organiser. Meeting up in person every couple of weeks helped make sure that we were making progress with what needed to be done, and together we came up with ideas that neither of us had on our own.

The event itself

The week before the inaugural Trans*Code Switzerland, Arielle and I were both pretty nervous. We hadn’t managed to get a particular sponsorship that would have been useful, and the stickers I’d ordered had not arrived. We weren’t sure how many people would actually show up at 9am on a Saturday, either!

In the end there were about ten of us, which meant we could all sit around a big table together and work on several different projects. We had enough power adaptors and croissants for everyone, no one minded about the stickers, and most importantly, someone in the office had found a fancy coffee machine hidden in a cupboard for us to use.

Some of us worked on collecting gender-neutral toilet locations from Open Street Map to add it to Refuge Restrooms, while another group researched trans-friendly holiday destinations. A third team decided to build a tool to find — or create — non-gendered names for nonbinary people. At the end of the day we videoconferenced with Naomi and the group who’d come to the first-ever American Trans*Code, in Chicago. Excitingly, a team there took up the nonbinary name generator and worked to improve it further.

In short, our hackday was a success and we are already planning the next one!

What’s this got to do with PHP?

You might have noticed that I’m writing on a blog about the PHP community, but this story started out when I went to PyCon and met Naomi, who’s on the PSF Board. Where’s the connection?

Well, one connection is me. Like quite a few readers here, I’ll bet, I code in other languages as well as PHP, but I’m still a member of the PHPamily and proud collector of elePHPants. It was with PHP that I first discovered the friendship and opportunities for learning that can be found in a programming community, and I’ve been directly helped by diversity initiatives here: last year, PHP Women sponsored me to attend Lone Star PHP, where I learned a lot. (Yes, I’m nonbinary, but PHP Women is inclusive and here for all minority groups in PHP.) PHP Women, and especially Michelle Sanver, are a huge inspiration for me in encouraging diversity in technology.

Another link between PHP and Trans*Code is that PHP is traditionally a very accessible first language. How many of us first got our start in PHP building a website in our bedroom or altering a WordPress theme? This makes it an attractive potential first step into tech for marginalised people, including trans people. That’s why, I think, there’s an overlap in audience for Trans*Code and 24 Days in December.

Setting up and running the first Trans*Code Switzerland has been a great experience for me. Now we’ve got the momentum, I really hope we can keep it up through 2017, and I would love to get more PHP people to join in too.

Coming 2017, this would be my first decade working on projects that involves an open source community driven PHP content management system that goes by the name of Joomla! To those of you who aren’t aware of what Joomla is yet, it is an open source content management system. It empowers 10% of the CMS marketshare

I have a love and hate relationship with the project but it has helped me in my own personal growth for the past decade. Although I am not actively involved in the development of Joomla per-se, I am extremely thankful and grateful to every volunteers that is involved in the project.

Amazing community

As it is an open source project, it is driven by an awesome community. There are ups and downs in the community as nothing is perfect but what amazes me is the way the community moves forward. The contributors for the project are not getting any salary, yet the project evolves faster than any commercial or enterprise projects that I have seen till date.

The people within the community are extremely friendly and helpful. Throughout these years, I have met with many great, light minded developers that gives me a lot of inspiration.

Ecosystem

Joomla! alone, isn’t entirely as powerful as one would envision but with the massive list of templates and extensions on it’s directory, it is what empowers the core. In a way, it is a pretty healthy ecosystem I would say as commercial developers may also contribute back to the project (be it sponsorship, man-hours in hunting for bugs or even helping out with the leadership team)

What have I learned

There is no technology or device that could last forever. One fine day, these great tools, services or devices will be a legacy but what certainly remains are the friends that we made throughout these years and for the years to come!

Reignite the vision

Everything has its peak and its downfall. It’s the same for Joomla back in the days, I believe many ones that I have personally worked with know this as well, the fact that we will definitely face our uphill battles sooner or later whichever platform you may choose.

It is a constant battle to seek for the impossible, unveiling opportunities that is before and not shutting the door for improvement and innovation. Therefore, I truly believe “No man is an island”, with a supporting community such as Joomla will definitely go the extra mile. Together and united, we could bring Joomla back to its glorious days or even greater.

Not an exclusive club

Joomla! is not an exclusive club reserved for people with a specific sets of expertise or talent. You could even contribute in some translation works even without any coding knowledge, get involved with various testings to identify a bug or two, if you’re a developer yourself, you could add a line of codes at Github projects and list goes on and on. It’s just that simple, hop on board and we will fill you in.

Do not stop learning!

Every journey has its humble beginning, therefore never despite your beginnings. My involvement in an open source working environment were never a smooth sailing one, in fact most of my past experiences were eye opening to me and it still is. Mistakes are our proof that we are still trying, and success are results of our hard work.

To end this, I truly hope that this post will inspire you to embark on new journeys and giving back to your community that you believed in. 😃

Merry Christmas!

I’ll start with just saying I’m a huge fan of history. I am also a huge believer that that to understand something, you have to not only know what the current situation is but how and why you ended up there (Event Sourcing applied to real life).

The history of the PHP community is really interesting, although I’m by no means the best expert on it (Although I’d highly recommend sitting down with Cal Evans or Ben Ramsey to chat about it). Ultimately, the PHP community developed in such a way that it consisted of various silos or micro-ecosystems. These silos are often based around projects but are sometimes also based around locations or languages. Ther PHP community has many sub-communities such as the PHP German-speaking community, or the US PHP Community or the European PHP Community or the Symfony Community or the Drupal Community. There is absolutely nothing wrong with this, and it’s fantastic to see so many different communities revolving around the wider PHP ecosystem.

However, in the past few years, probably down to a few select factors (Composer, OOP, the FIG and more conferences), I feel like the walls are being beaten down between these different communities and that’s a wonderful thing too.

In terms of code, people are sharing libraries a lot more, and the phrase ‘Proudly invented elsewhere’ has become something that people not just say but something people are exactly as the term describes, they are proud to say it. This has been made possible through things like proper OOP/namespacing in PHP and composer; but also a wider attitude change in that no longer is it the case that rolling your own and reinventing the wheel is the first go-to solution (where previously it often would be, and you’d only use someone else’s package if you found it difficult to solve yourself).

On an in-person level, I see more and more new faces at conferences each year, both speaking and attending, at generalised PHP conferences and these people are often people who have been to Symfony or Drupal or WordPress conferences before, and just beginning to reach out to the wider PHP community. Jenny Wong did an amazing keynote at PHP UK a few years ago on just this, the integration of the WordPress community into the wider PHP community which I’d highly recommend watching.

Finally, and most importantly to me, is that different communities are seeing the value in working together towards shared aims. Some years ago, it would have perhaps seemed impossible to think that the frameworks Zend Framework, Symfony, Laravel, Slim could all be sitting around the same table working together; nor that consumer applications phpBB, Drupal, Joomla and eZpublish would also be sitting around that same table, also working together. Yet this is what the PHP FIG has shown (both physically at php[tek] in 2009 but also a body with all of these projects having been members) is possible when people look towards the future and work together. We all have so much we can learn from each other because all these different projects have their own experiences and expert pools, and the fact we’re all willing to teach each other these things in this multi-directional street ensures that everyone benefits. The new PHP FIG mission statement addresses this:

The PHP FIG aims to advance the PHP ecosystem and promote good standards by bringing together projects and people to collaborate

The PHP FIG’s primary aim is not to create standards for technical interoperability, but to bring projects and people from all over the PHP ecosystem together so that they can work together towards common aims.

I believe this is the future of both our industry and our community: with PHP projects that are essentially competitors (including financially in terms of the companies backing these frameworks and applications) working together on shared and common aims. This would both increase the monetary value of our entire ecosystem; but also makes all our lives as developers easier and promotes better package development and optimal usage as developers choose which framework and application they want to use based on their needs and wants as opposed to requirements due to ugly dependency trees or the inability to change your caching library.

I’m going to be honest: I was going to write a blog post about being a polyglot, how my year has been while branching out from PHP, and to encourage the community to stop being toxic about other technologies and communities, but Lorna beat me to it.

Instead, I want to flip it on its head a little bit. I gave a keynote at PHPConf.Asia earlier this year that, quite frankly, didn’t go over well (in my opinion) and left me feeling like I failed to deliver the message I wanted to give. I’m going to try and clarify what I wanted to say here.

By some metrics, and if you listen to the haters, PHP is a dying language. JavaScript is the “future of the web”; single page applications, JavaScript everywhere. And yet, per the same stats, JavaScript is also declining (source). And while new languages such as Rust and Golang seem to be surging in popularity, compared to any older language they barely register on the scale.

Meanwhile, PHP still maintains an 82% majority share of the web, and WordPress dominates in the content management space with 27% market share. If that weren’t enough, the top four CMSs are all written in PHP, totaling 34% (source).

We’ve also had at least two releases of PHP a month since February 2012. As a community, we are definitely doing something. In fact, we’ve added more than forty notable features since PHP 5.4 (inclusive).

But this only tells you about the language, and frankly, even if there had never been another release after PHP 5.3, we as a community have grown and matured immensely since then.

Last month marked the second time we’ve had more than 200,000 packages installed from Packagist (243K in fact, up from 186K when I gave this talk in August!), and there are over 119K packages available now (source).

We have more — active, healthy, and well maintained — opinions on building software (otherwise known as frameworks) than you can shake a stick at.

And yet, this idea that PHP is dying, or dead, still pervades the greater tech community. This is nonsense, and we owe it to ourselves, and our community, to combat this message.

I have had to defend my choice of language many times over the last few years, and it’s easy to do, thanks to the work of the community. We have a mature object model, a language spec, an amazing package manager, the best documentation, and more besides.

Choosing to use PHP does not make you a bad developer, and you should be proud of the things you accomplish with the tool rather than the tool you chose.

As a community we can do one thing better than any other: build the web at scale. We must get out into the wider technical community and spread our knowledge. I’m not calling on you to prosthelytize PHP, I’m asking you to take the knowledge you have and apply it to other languages.

PHP has always been a glue language. Everything we glue together has nothing to do with the language we’ve chosen. Things like using Varnish for caching, using Cassandra for sessions, building good relational database schemas, effectively using NoSQL datastores, and building work queues with ZeroMQ.

While we should continue to do this, we also have a responsibility to look to the future.

HTTP/2 The Future of the Web is Coming

If you follow me online at all, you’ll know my last year has been focused primarily on HTTP/2, so there’s no way I could not mention it in this post.

I truly believe that HTTP/2 has massive potential to change the way we build the web of tomorrow. Multiplexing and Server Push, alongside weighting and dependencies, mean the architecture of delivering assets of HTTP is going to need to be much more considered, and drastically different, to take advantage of the performance benefits made possible by HTTP/2.

But even if every other language except PHP embraces HTTP/2, the best we can do is improve 18% of the web.

This is why the PHP community needs to take a leading role in the adoption of HTTP/2. We need to experiment to create best practices. We need to deploy it and measure it. Above all else, we need to embrace what it means for us as application developers.

PHP as a language, unfortunately, just isn’t built for multiplexed responses, and we currently dodge this by pushing the responsibility up to the HTTP layer using Link headers.

But this will only get us so far. We need to work with the HTTPd vendors and the internals team to figure out how to communicate between the two in a way that allows for multiplexing. As I’ve said before, we need a new SAPI (thanks for the inspiration Jack!) and we need to rethink how we architect our applications.

You should get involved in efforts to figure this stuff out.

We owe it to the web to lead. Do you want to do your bit?

Earlier this year, I started a new job. One of the reasons I picked it was because I would get to evaluate whether or not the existing PHP codebase was up to snuff, and what we were going to do about it. The project owners were developers but they weren’t PHP developers, and the codebase had just been worked on by contractors for many years. It was a situation of “It works, but we can’t tell you how good it is.” There was a feeling that it would not be a good code base to continue with (framework-wise, not language-wise).

The last major overhaul had seen the project move over to what I will term a “home-grown framework,” one that is not in wide use. It was old and the original developer had moved on, so the framework was effectively unsupported. Internally the framework just kind of stood there like an old factory that, while not falling over, had not really been cared for.

There were no unit tests. Nothing was really automated. API output was inconsistent. Coding standards were expected but not documented or enforced. Documentation was nearly non-existent or out of date. There were a lot of broken windows.

If you aren’t familiar with the Broken Window Theory, here it is:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people start leaving bags of refuse from take-out restaurants there or even break into cars.

-James Q. Wilson and George L. Kelling, The Atlantic Monthly, March 1982

The longer these “broken windows” stay around, the harder it is going to be to fix them, and the more likely developers will continue to allow the broken windows to stay broken. Have you ever tried to put in unit tests into a legacy application? The older that the app is, the harder it will be.

Now, I have full authority to just say, “Screw it, we’re starting over fresh” and greenfield the project. I am not going to though. There’s a lot of history in this not-so-great code, a lot of bugs in the business logic that have already been fixed. I’m sure some of the bad decisions are there because they have to be, because not all code works perfectly when integrating with external services. If I rebuild the app, we’ll just make those same mistakes again.

So I’m taking the initiative to fix those broken windows. It’s a bit more work, but in the end it will be better. What am I doing, and what can you do to fix the broken windows?

Establish Standards and expectations

The first thing to do is establish some ground rules around standards. I’m laying out what our code workflow will be. There’s no ambiguity about how an issue goes from being reported to our master branch.

I’m finding standards that are well established, like PSR-2, and starting to enforce those things on new code. PHP CodeSniffer has a PSR-2 sniffer built in, so I’ve written pre-commit hooks to alert developers when their code might conflict with PSR-2. We mostly follow it now anyway, but it’s good to come right out and say “Hey, this is our coding standard, and here are tools that tell you when your code needs some love.”

I’m also encouraging the idea of Object Calisthenics. We’re going to be growing our team so we can’t work like a lone cowboy coder anymore. Cleaner, easier to read code helps everyone.

Documentation

I’m a writer, yet I hate writing documentation. It’s now just going to be a rule that new features will need to have corresponding documentation. If we change how an endpoint reacts, we need to also make sure that the PR includes the documentation update.

If a new feature is added, it gets documented. Inputs, outputs, and expectations will be laid out.

PSR-5, while not accepted yet, is a good starting base for our code documentation. Again, this is something we do already, but it makes sense to mark down what we follow.

testing

This one is going to suck, but new code will have to come with unit tests. I fully understand that the legacy code will be hard to unit test, and I’m not expecting us to get to 100% code coverage any time soon. And I know that some bug fixes will be very, very hard to unit test. What we will be doing though is on new code, it is expected to have unit tests. If it can’t, we document in the code why something isn’t unit tested so that we can find it later. Then make a unit test and just skip it. The idea will be that when we can better unit test the surrounding code, we’ll be able to revisit and make those skipped unit tests work.

As with the CodeSniffer, I’ll be supplying pre-commit and pre-push commits to make sure that as we build up tests that they are run automatically.

Code Reviews

This is another hard one. No one likes to have their code critiqued, but in a team situation having code reviews is a healthy way to find potential problems before they make it to production. All of the automated tools in the world can’t find logic or workflow issues, and no matter how well you unit test something you’ll never find all of the weird things that users will try and do. Github and Gitlab both have excellent peer review software baked into their PR systems.

Follow Through

I proposed many of these ideas with my coworker, and while receptive, I was met with, “Yeah, I’ve heard that before.” It’s one thing to say you are going to start doing these things, and it’s a whole different thing to actually do it. And commit to it. Push back when things aren’t followed.

In the immortal words of Shia LaBeouf, “DO IT.”

There are plenty of things that we as developers can do to help fix our broken windows. It might not be as glamorous as burning down the house and rebuilding it from scratch, but at the end of the day, you’ll have a better codebase.

And that’s all I really want for Christmas.