In a new post to his site Tomas Votruba has shared a list of five things that he, as an open source package maintainer, had heard before getting started.

I wasn't always confident while making public every single line of PHP code I write. I had to take many blind paths, spend a night full of stress coding in unknown waters and make a lot of over-complicated code that backfired to me months later.

They say "experience cannot be passed and it must be experienced" and I agree with that, but still there are some shortcuts that would speed-up my path to joyful open-source coding I have today. Here are 5 of them.

He then shares his suggestions, each with a brief summary explaining what it means and how you can apply it:

1. Be Open to Change any Package
2. Don't Keep Every feature You Have
3. Lock to LTS, Maintained Dependencies and green PHP
4. All You Need to Maintain is 1 Repository
5. Don't Take Advise as Granted, Experiment for Yourself

He includes some of his own backstory in several of the posts about his own development work and how he found out some of these "the hard way".

Matt Stauffer has posted the second article in his "Enterprise Laravel" series to his site. In part one he started with a practical approach to seeing how large the codebase is (counting lines). In this new post he takes an example situation (gathered from conversations with other developers) and shows how Laravel can fit its "enterprise" level needs.

Recently, I grew tired of hearing people say, "Laravel is fine for small apps, but when you are working in the Enterprise..." You can almost hear the capital E in enterprise, like they're talking about the starship.

I've spent the last few months trying to gather information about what makes people say this, and also stories of folks who are already successfully working with Laravel in enterprise context. I put out a <a href="https://enterpriselaravel.com/success-stories-survey>survey to collect stories, and wrote and delivered a talk (which I hope to give again soon) titled "Laravel and the Enterprise."

The idea, stemming from a submission via his "help me" form, is an application that lets customers create their own white-label storefronts for clothing. He starts with the submission itself and the issues it points out including:

• the load caused by adding a new tenant (requires more servers)
• a messy codebase
• a more "monolithic" approach as it evolved away from simple CRUD

He then goes through each of the (five) points made and his responses trying to help mitigate the issue. Some of them come with more technical recommendations but for others the answer is more about documentation and processes.

On the Stitcher.io blog there's a new article posted about a programmer's cognitive load and offers some tips to help reduce it, especially when reading code that's new to you.

Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

[...] Today I want to share some techniques that can help you reduce this cognitive load while coding. In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase. We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.

The tips they article make use of some of the most common features of IDE including adjusting fonts and spacing, using code folding to reduce visual noise and effective naming. Each point has either screenshots or code examples to help illustrate the point.

On his site Josh Lockhart, author of Modern PHP and the Slim framework has shared advice for aspiring PHP developers, mainly centering around one core idea.

As a fledgling PHP developer, I aspired to be in the same league as legendary figures like Cal Evans, Chris Hartjes, Larry Garfield, Anthony Ferrara, Paul Jones, Sebastian Bergmann, Taylor Otwell, et al. I consider these folks members of PHP's inner sanctum, so to speak. They are decision makers, tool builders, and opinion shapers.

[...] My advice to aspiring PHP developers: there is no great Wizard of OZ. There are only opinionated men and women behind a veil of authority who bicker of politics and standards. It's not magical. It's messy. It's a minefield of polarizing politics, sensitivities, and opinions.

He points out that, no matter why you say or do, there'll always be someone that will take it the wrong way - it's just human nature. He uses a recent example of an interaction he had with another member of the PHP community around contributor guidelines on a project.

Aspiring PHP developers, stay above the fray. Don't seek out a Wizard of OZ. He does not exist. PHP's inner sanctum isn't worth your time. Instead, do your research, recognize and avoid propaganda, and trailblaze your own path.

The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

Ondrej Mirtes has offered some advice in this Medium.com post sharing some of his experience in the development and management of his PHPStan project (static analysis for bug detection).

Most developers have side projects. That's how we try out new things or make something that we miss on the market or in our dev stack. But most side projects end up unfinished and never actually see the light of day. And even if a developer builds up the courage to show his work to the public, he quickly finds out that just publishing a repository doesn't actually bring the masses to his doorstep.

At the beginning of last December, I released PHPStan? - ?static analysis tool for PHP that focuses on finding bugs. The project gained a lot of traction resulting in currently over 1 300 stars on GitHub and more than 30 000 downloads on Packagist.

He spends the rest of the article sharing the things he did to make sure that the project "didn't end up in the dustbin of history" and be successful. Topics include:

• Build the hard stuff first
• Serve market needs
• Promotion
• Ask for money

He ends with what he sees as the most important part of any good open source project - as a maintainer you need to "be nice". This means being responsive to incoming feedback, keeping in mind that people contribute/comment because they care about the project (and it's not usually about you).

Matthew Turland has an interesting new post to his site sharing some of his own thoughts on how you can stay employable as a developer with some great suggestions both on the technical and personal side.

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

His suggestions touch on topics like:

• length of employment at one company (sometimes based on the type of company)
• the balance between being a generalist and fitting only into a niche role
• constant learning (and spending time "off the clock" doing professional development)
• networking with other people

There's a lot of good content in the post so be sure to give it a read, especially if you're a developer that's been in the same role for a while...

On the JoliCode.com blog there's a post sharing the experience of writing an API client with PHP including some advice to those out there considering doing the same.

My (love-)story with Docker started in December 2013, after having lost a 2 years long battle against Chef. I had been attracted to Docker for a couple of months, and I finally made the switch the day when I learned that it was built on a REST API. This meant that I could control all my infrastructure from PHP, which is the language I’m most partial to.

After some research, I found the library docker-php built by ubermuda, but, like all the things around Docker at that time, there was only a very limited support of the API. Like any decent developer (yes, it’s a troll), I started to write pull requests to fulfill my needs, and it was both the greatest and the worst thing that happened to me.

The post starts off with a brief history of PHP libraries working with HTTP requests (and the difficulties he had with Guzzle). This includes the fast pace that the library was changing at the time, making it difficult to keep the code maintained. He took a "step back" and decided to look more into HTTPlug and some changes to help bring it up to date. With that choice made, he got into the automation portion and using it work with the Docker API. He talks about some of the other technologies and tools he investigated along the way including Jane for working with JSON message schemas.

Maintaining an open source library is hard and takes time. However, these last years made me realize that we can control it, by moving features into other projects, trust people behind it, and by reducing the feature sets.

On the QaFoo blog there's a post sharing some of what they've learned about the common bottlenecks in performance testing and some things you can to do determine the issues in your own tests.

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

If you've been thinking about starting a local technology user group in your area but have been looking for some guidance, you should definitely check out this recent post from Joe Ferguson with some good "dos" and "don'ts" around groups and organization.

When I introduce myself before I give a talk at a conference or a user group I mention I am a user group leader and very passionate about community. I happily receive questions from people starting new user groups or reviving old groups.

I wanted to share a recent response I sent to someone today who was asking for advice about their meetup group: Congrats on jumping into the world of running a UG. A lot of this is “in my experience” so your milage may vary

He starts with the "dos" (like keeping it small to start and making meetings consistent) and "don'ts" (not to worry about sponsors and making the talks "conference level" every month). He also includes an interesting section about "protecting" your user group, preventing things like over-zealous recruiters from coming in and giving people a bad impression of the group. He also links to lots of other resources you can read and participate in to make you a more effective user group leader.