In a new post to his site Nikola Posa takes a look at naming conventions in code and makes some recommendations based on his own work.

In the last couple of months, I spent a lot of time studying Proophessor Do demo project that showcases features of Prooph components, all with the aim of mastering CQRS/Event Sourcing concepts. Along the way, something else turned my attention away from the main topic - unconventional, but clean and concise naming convention for class and method names.

This was a true eye-opener for me, I immediately liked the idea and after adapting it a bit I started practicing it at work. Excited and full of enthusiasm, I shared my findings and opinions with the rest of the world.

He tweeted about his excitement but found that there was more to say and a blog post was the place to put it. So in this post he covers several "anti-patterns" to avoid in code naming conventions:

• Anti-pattern 1: Prefixes/suffixes convention for Interfaces
• Anti-pattern 2: Archetype suffix convention for domain classes
• Anti-pattern 3: "get" prefix convention for property accessors

He finishes the post with some final thoughts and a "TL;DR" image showing a "right" and "wrong" way to structure your code.

In a recent post to his site Eduards Sizvos shares an opinion that's believed by many in the development world: stop learning frameworks.

We are developers. We need to stay up to date with technology. Every day, we learn programming languages, frameworks, and libraries. The more modern tools we know?—?the better.

Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

But we are wasting our time.

He goes on to talk about time, how important it is to spend on the right things and offers a story of his own where learning specific technologies didn't help in the long run. He then shares some resources (books) to help you learn good concepts instead of specific tools.

Remember – frameworks, libraries and tools come and go. Time is precious. Invest your golden time in transferable skills. Skills that will always be relevant.

In a new post to his site Leonid Mamchenkov talks about complex arrays in PHP and links to two articles offering different opinions on their use.

Now that PHP 7+ sorted out a whole bunch of problems with type-hinting of parameters, return values, variables and properties, we turn our attention to somewhat deeper issues.

Array is a native citizen in PHP. Arrays are very convenient and are widely used. However, if you stop and think about the times where you had to figure out somebody else’s code, I’m pretty sure complex arrays will come to mind at some point.

The first article takes the positive approach, showing you how to create better handling for complex arrays in your applications. The second takes the opposite approach, showing how to avoid complex data structures in your code, opting for classes and objects instead. He notes that he thinks both articles have their good and bad points and references another blog post of his that provides yet another way to solve the need for complex data structures.

Freek Van der Herten has made a new post to his site sharing some of the things he thinks that could help to improve PHP conferences in general, not just ones in a particular area of the world.

The past year something has bothered me about the traditional formats most conferences in the PHP ecosystem seem to adhere to. I recently went to DotJS: a JavaScript conference which was organized very differently from the majority of PHP conferences I attended previously.

In this blog post, I'd to highlight what PHP conferences, in general, could consider copying from a conference like DotJS.

Among his suggestions are topics like:

• shortening the talk length
• making lightning talks a "first-class citizen"
• appointing a Master of Ceremony
• avoiding the Q&A portion of the sessions

There's a few other suggestions he offers to around audience seating and how many tracks to have. He spends some time on each point, explaining some of his thoughts and how it relates back to his experience at other conferences outside of the PHP community.

In a new post to his site Tomas Votruba shares his opinions on project structure and when he sees it appropriate to use a "monorepo" and when to use packages to compose your application.

Recently I gave a few talks about monorepo in PHP and how to integrate it to companies in a useful way. I'm very happy to see many people already use it and know what problems it solves.

Before monorepo hype takes over private PHP projects, I think you should know about its limits: When is the best time for you to go monorepo? When you gain less complexity while integrating it? How can you make the transition better? Is it really needed?

He starts off by describing some of the most common application structures including the monorepo, many-repository, and local package approaches. He sees each as an evolution on the previous and shares when he thinks the evolution makes the most sense (hint: it's about value). He ends the post by sharing a few final thoughts about monorepos and when they make sense for private projects versus public, open source projects.

In a recent post to the Hackernoon site, Sergii Shanin shares his take on the "PHP is dead" conversations and posts out there with the expected "Viva le PHP!" (long live PHP!) following it.

The fracas over Gutenberg and WordPress is the latest installment in the death of PHP. Take a deep breath everybody. Let’s ignore the trolls and take a look at what Mark Twain, Fidel Castro and PHP have in common?—?and more to the point, why PHP is still a reasonable choice for startups and small businesses.

t looks like ‘PHP is dead’ blog posts started cropping up in 2011 (let me know if you find older ones). If you search around Medium and the coding bootcamps that are popping up like mushrooms, the only common denominator is that everyone hates on PHP or simply ignores it. Apparently, it’s impossible to code in PHP with an oiled beard and ironic t-shirt while drinking overpriced coffee.

He shares two of the most wide-spread myths about PHP - that it's slow and that it can't scale - and dispels them. He then goes through some types projects where PHP "shines" including content driven websites and e-commerce sites. He shares some the "business sense" around choosing PHP, the perspective senior PHP developers bring to teams and projects, and the seeming "nine lives" of PHP.

Tomas Votruba has written up a new post to his site covering the sorting of private methods in classes and why he considers it important to the quality of your code.

When I started PHP in 2004, all you had to do is to learn a few functions to become the most senior dev in your town. Nowadays, devs have to learn a framework, IDE and coding patterns to get at least to an average level.

Instead of reading 346 pages of Clean Code, you need to produce code and learn as you read it at the same time. There will be never less information than it is today. That's why effective learning is a killer skill. Today we learn how to sort private methods in 2 mins.

He starts off by talking about why private method ordering is important, giving an example of a simple class with several private methods. He suggests that, by ordering private methods within the class more related to the functionality that uses them, developers in the system can more easily relate the functionality. He also includes an example of his the PrivateMethodOrderByUseFixer coding standard service to automate this in your code.

Christoph Rumpel has posted a recap of his experience at Laracon EU talking about chatbots and some details on the chatbot he created for the event.

For my book and video-course about building chatbots in PHP I created the Laracon EU conference chatbot. In this article, I will give you all the insights into this project.

On the 12th of July this year, I released my first ebook/video-course called Build Chatbots with PHP. In the last chapter, you can follow me as I create a chatbot for a real client: The Laracon EU conference chatbot. A chatbot that was made to provide information about the Laracon EU conference on <a href="https://m.me/laraconeu>Facebook and Telegram. This article is about my learnings of this projects.

He starts off by talking about the desire to "be real" with his example and how abstract examples, while helpful in the short term, don't provide much value past that. He created the course with this in mind, providing a real-world example to show users the ins and outs of chatbots. He also suggests not messing up the first implementation and points out that chatbots work great with events. He covers some of the features of the bot and how he worked around some differences between the two social media services. He ends the post with some statistics of the users of the bot and the feedback he received.

In a recent post on their own site, thePHP.cc has shared some of their own perspectives about the recent future of Zend announcement. For those that aren't aware, the company that acquired Zend several years ago - Rogue Wave - announced their decision to discontinue their support of the Zend Framework project.

Last week, Zeev Suraski, Matthew Weier O'Phinney, Enrico Zimuel and Dmitry Stogov, all well-known members of the international PHP community, announced that they will leave Zend, which has been part of Rogue Wave since 2015.

The stated reason is Rogue Wave's strategic decision to focus on the development of Zend Server. If you read between the lines, this implies that Rogue Wave is not going to continue or support the development of the Zend Engine (the core of PHP responsible for compiling and executing code), their IDE Zend Studio, and Zend Framework.

Of course, it is perfectly valid to make money off an Open Source project. This, however, implies at least a moral obligation to give back to said project. Rogue Wave, it seems, will now terminate the symbiotic relationship between PHP and Zend.

The author (Stefan Priebsch) talks about "lip service" not being enough when a company wants to make money from customers but aren't willing to help with the development of the underlying software. He also mentions several other Zend-related products that have a bit more quietly gotten the axe over the years since the acquisition. He wonders about the "downsizing" this could cause in the PHP community given ZF's impact and how, despite this being a large setback for the project, he sees its future as promising given the people involved and the projects around it.

On the TechBeacon site they've posted an article about choosing the right testing tools for your codebase and why making the right choice matters.

Fast end-to-end tests are the next big thing. The tooling has improved tremendously, and the productivity and insight gains are too good to ignore. Modern tools such as Cypress and >TestCafe are becoming quite impressive and can give you confidence in your product's quality.

As with most facets of software development, there is a balance to be strived for between speed and test confidence. The leverage point depends on the project, and the two most common types of software project these days are web services and enterprise software.

They talk about some of the differences between the testing of web services versus enterprise software as well as some of the practical advantage of fast tests. They also cover the advantages of broad tests and cover some of the current tools for testing including Cypress.io and Laravel Dusk.