On the Zend Developer Zone there's a new post talking about scheduling in applications ("scheduling elePHPants") including both library recommendations and advice about code reuse.

It was while I was creating the 100th or so cronjob to do some very similar to the other 99 that I thought, “Hey! Why not just put all this in a database and check it once a minute instead?” [...] It would be so much easier to deal with in PHP. Also, cron does not scale well at all either in performance or management.

The problem is that cron is an elegant solution for “Do this at that time” type of problems. Every solution I came up with was basically re-creating cron. That in itself isn’t a bad thing, but the logic involved in doing what cron does is mind-melting.

[...] Then it hit me, I am probably not the first person that has had this need. There have probably been other people who needed to implement “Do this at that time” within a PHP application. So I started looking around. What I found was encouraging.

The author then mentions several packages that he went through searching for the right solution to his problem, noting that while Laravel-based solutions seemed nice, they wouldn't work with his framework choice (Slim). He decided on the cron-expression package, finding it to be the best fit for the project's needs.

I had spent countless hours trying to create the solution myself. [...] I got so lost in solving the problem, I forgot to look to see if someone had already solved it. [...] After I finally came to my senses, I tweeted that out to remind myself to “Use the Source”.

On the Dailymotion.com Engineering blog there's a recent post detailing their experiences moving their services to PHP 7 and some of the discoveries they made along the way.

In march 2015, we started to think that code refactoring and architecture improvements, will not be the only way to optimize the response time on dailymotion.com. This is the core problem of websites with high load : “how to scale without investing too much in people/servers”.

They started out by looking into Facebook's HHVM project to potentially replace the default PHP interpreter with a better performing core. They mention incompatibilities they discovered and some of the results in testing it on a handful of servers in production. They had some time to play with things so they waited until PHP 7 was officially released and tried that to make an equal comparison. In the end, they ultimately chose to go with PHP 7 as it was the route with less "friction" and work on changes for their current codebase. The post also includes graph output of some of the improvements they saw when

On the Slack Engineering blog there's a new post from one of their engineers talking about a choice the company made about their platform - they decided to take PHP seriously. In this post author Keith Adams talks about why they chose PHP and what kind of experiences they've had with it in their own environment.

Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?

PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options for improving on PHP’s language-level flaws are pretty impressive. On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.

He starts with some background on the history of PHP itself, where the language came from and what kinds of issues it tries to mainly solve. He then gets into some of what he sees are the "virtues of PHP" including the blank slate at the start of every request, one-request-one-process concurrency and the fast programmer workflow. He then gets into the "bad stuff" they've found when working with PHP, things like surprise type conversions, a "failure-oblivious philosophy" and inconsistencies in the standard library. Finally he looks into two options (created by Facebook to improve its use of PHP) - HHVM and the Hack language - and how it was integrated into their environment.

On the Laravel News site there's a post sharing some of the results from a recent request for feedback from Taylor Otwell (creator of the Laravel framework) asking the Reddit community for their own experiences contributing to the Laravel project.

Taylor created a feedback thread on Reddit asking the community on why they do not contribute as well as asking for suggestions on how to manage issues.

Taylor said in the thread, “One thing that has been bothering me is I have seen a few people say they don’t contribute to Laravel because it seems like PRs get closed or shot down without much explanation. [...] Taylor continues, “My biggest challenge is the “Issues” tab on GitHub. It gets a lot of activity and its hard to filter out genuine issues from support requests, configuration problems, general questions, etc”.

Among the opinions shared in the responses were comments about how feedback was given by a certain member of the Laravel development team. Taylor has already said that processes have been put in motion to help make this situation better and move people to where they're most productive. The thread and shares a lot of other opinions besides just this, so if you're considering contributing it's worth a read.

Documentation can make or break a project but it's often completely overlooked until the very end. And if we don't think about how developers will interact with our project before writing our opening We'll discuss some strategies we can take to improve the overall developer experience with "good" documentation and clean API's

For those that weren't able to attend this year's PHP South Coast conference (in Portsmouth, UK) Matthew Setter has posted a wrap up of some of his experiences there and what the conference was like.

I’m on the train heading to Stansted airport, after what I can only describe as a brilliant weekend in Portsmouth, attending the inaugural PHP South Coast, conference. I’ve not been to Portsmouth for 10 years, but the wait was well worth it.

He talks about the venue where the conference was held and some of the talks that were given during the day long event. There were two tracks so, unfortunately, he wasn't able to attend all of the talks but he does provide summaries for those he was able to attend. He also spotlights the opening keynote from Cal Evans about the importance of community and how it relates to your career. He ends the post talking about something he found quite valuable: meeting people, both those he knew from online and others just attending the event.

So...testing. That thing that everyone says is so important but you don't really learn about it in school. I've had some trials and tribulations with testing so I'm going to just dump out some thoughts here.

He starts with a bit of background on his own experiences in development and how he finally decided that testing would "solve everything". He started with unit tests (for a CodeIgniter application) and how he got them up and running. He talks about issues he found around dependencies (and static methods) and how he made use of mocks to reduce some of the issues with dynamic loading, at least how CodeIgniter does it. Unfortunately, this didn't work out as planned so he fell back to a test database and create more effective and simpler functional tests. Code examples are sprinkled through out the post to show how he was trying to solve the problem at different points in the process.

The Full Stack Radio podcast has posted their latest episode today, episode #17, hosted by Adam Wathan and featuring guest Adam Culp. Adam and Adam talk about ways you can maximize your conference experience.

n this episode, Adam talks to Adam Culp, organizer of Sunshine PHP and ZendCon. They talk about how to get into conference speaking, how to make the most of a conference as an attendee, as well as tips for running a great local user group.

The Three Devs and a Maybe podcast has posted an episode recently talking about some of their own experiences at conferences, RFCs and an interview with special guest Phil Sturgeon.

This episode we are fortunate enough to have Phil Sturgeon back on the show. Originally recorded on the 11th Feb and only now being released (blame Edd), the show starts of with a comparison between Phil and Fraser's snowboarding injuries. We then move on to discuss standing desks, Sunshine PHP, American weather, and conference experiences. Following this DDD (Development Driven Development...) is touched upon, along with a look at the current stack Phil is using at work. Finally we chat about the 'attack-of-the-clone' packages Phil has noticed around the PHP community (ultra-tiny-small-restful frameworks etc.) and how far the 'The League of Extraordinary Packages' has grown.

The Voices of the ElePHPant podcast has posted their latest episode today in their series of community member interviews. In this latest episode host Cal Evanstalks with Ryan Weaver.

In this episode Cal and Ryan talk about the concept of "developer experience" (DX) and how the Symfony project has been working to make things easier. DX tries to make things that developers find consistently complex and simplify it. Ryan is hoping the concept will spread outside of the Symfony community into other groups.