php[architect] magazine has shared another article from their April 2018 issue on their site. In this article Ondrej Mirtes covers the use of static analysis to help testing and inform you of type safety issues.

When developing an application, our aim as software developers is to make sure it does what it ought to do and to keep the number of defects as low as possible. [...] In this article, I’d like to introduce you to the concept of type safety and how it can improve the reliability and stability of your code. Once your code is more type-safe, and that fact is verified by automated tools, you can cherry-pick which parts of your application need extensive unit tests and where you can rely just on well-defined types.

He starts off by talking about types (strict and dynamic) in PHP and the current state of the typing system for variable values. He covers the role of good type hinting in method and function definitions and how it can help IDEs like PhpStorm locate issues. He also talks about how type hints can provide you feedback on the design of the application and some of the tools that can help you find issues.

He wraps up the article with some tips for making your code more strongly typed and a look at what kind of tests are needed to help ensure these types remain enforced.

Freek Van der Herten has a new post to his site sharing what he considers some of the most helpful Laravel package to help with your debugging.

In this post I’d like to share some of the packages that make developing a Laravel app easier.

His list of packages includes a wide range of testing tools like:

• laravel-debugbar
• laravel-ide-helper
• laravel-tail
• laravel-mailable-test

For each item on his list he includes a screenshot of it in action (either of a terminal or a UI) and a brief explanation of how it can help.

Lorna Mitchell has a post to her site sharing a "call for help" related to the open source project she's a lead on: http://joind.in (a popular conference rating/feedback site in wide use across the PHP community). In her post she asks for help with the project and how you can help continue the success of the project/service.

This post is about the open source project, Joind.in. Joind.in is a tool to allow attendees at conferences or other events to offer immediate public feedback to speakers and organisers at those events. Joind.in is an open source project run by volunteers. For the last 6 years I've been a maintainer of this project, following a year or two of being a contributor. Over the last few months, myself and my comaintainer Rob Allen have been mostly inactive due to other commitments, and we have agreed it's time to step aside and let others take up the baton.

She then lists some of the things the project needs help in including:

• manually check and approve events (the volume of spam we get is surprising, events are manually approved)
• review and merge pull requests across the repos in [the project's] Github organisation
• maintain the issue tracker, keeping it tidy and tagging issues, replicating bugs
• managing the @joindin twitter account - responding to questions and we often like to tweet to promote events and CfPs as well

She ends the post with an update for those that wonder if this is "abandoning" the project, reinforcing that focuses have shifted more to "keeping the lights on" rather than abandoning the project overall.

Open source is most powerful when we pursue our passions and my journey as a speaker and event host over the last 8 years or so would have looked very different without joind.in. [...] If the project isn't important, it will keep on winding down. If it is important, the community will pick it up - this wasn't originally my project, and now it is time to hand it forward.

Lorna Mitchell has posted some preliminary PHP7 benchmarks from the current alpha release (alpha2). Good news - it's fast....very fast.

If you know anything at all about PHP7, you probably know it's fast. But did you know how fast? The alpha is out and looks very robust, so I decided I would create a new set of benchmarks to include it. Graphs first, disclaimers later :)

This graph shows the time it takes for each version of PHP to perform the same task, on average, with oldest PHP on the left and moving forward in time. [..] The benchmark is the Zend/bench.php that lives in the PHP sourcecode (run ten times for each version of PHP using the php7dev VM on an average laptop, and then the mean result for each version calculated). The script runs through a series of taxing algorithms, giving a sense of how quickly a series of computational instructions can be executed.

She also talks briefly about how this can effect more real-world applications, how realistic it is to upgrade from older installs (much less painful on 5.5 or 5.6) and some things you can do to help improve PHP7 for everyone. This includes testing, working on bugs and adding extensions to this list to ensure they're made PHP7 compatible.

For those looking forward to PHP 7, there's a new series of posts from Damien Seguy that can help you with some of the newer error messages and what might be causing them.

The first step to prepare for PHP 7 is to lint it : using the command line instruction ‘php -l script.php’, one can easily check that every file in a current application compile with PHP 7. The second step is to run the application and the unit tests : in short, execute it with PHP 7. And this is where we’ll learn about the new errors that PHP has prepared for us. In order to be one step ahead of the migration, this article will help you prepare here is a panorama on PHP error messages.

In part one he looks at some of the most often raised errors including the incorrect use of "$this" and undefined offsets. Part two gets into a few more complex messages about return type hinting, the constant scalar expression and using temporary expressions in a write context. Finally, part three looks at messaging around redefinition of identical parameters, bit shifting by a negative number, named constructor deprecation and strict typing. Each part of the series covers a few more than just the ones listed here too, so be sure to check each for more helpful error messages and solutions.

In this new post from Dawn Casey (wife of the infamous Keith Casey) she talks about some of her "growing pains" around becoming a new developer and the learning process. She's come up against some interesting problems in the course of her learning, both good and frustrating.

In the course of my learning development (seven months at this point) I’ve heard quite a few things from other veteran developers, all of whom were trying to be helpful. Or I’d ask a question and get one of these things in response because it makes sense to *them*…they don’t realize I have no point of reference. [...] I’m frustrated because they can’t explain whatever it is I don’t understand..mostly because I don’t understand exactly what it is I’m not understanding.

Her frustration comes not only from not being able to ask the right questions, but also from being a "blind deaf alien" thrown into the world of development. She point out an issue common to those trying to get into programming: the wealth of information one needs to know before getting started. She also mentions another common problem, particularly for new developers (or those looking to improve one certain skill): the sometimes unhelpful nature of other, more experienced developers. While some are happy to help and guide you through the learning process, there's others that will just toss you a tutorial link and call it a day.

Here’s the gist of what I’m saying: There is so much back-knowledge needed to be a web developer today that many are derailed for months trying to learn everything they need to know before they can learn anything at all. PLEASE REMEMBER THIS!!

On Matthew Ssetter's "Master Zend Framework" blog today he talks about simplifying unit testing and some of his experience with getting too complicated in his own testing practices.

Recently I was a bit stuck, trying to figure out how to test a section of an application I’ve been developing. Specifically, I was trying to mock a HydratingResultSet in a controller test, so it could be the return value of a method call on a datasource, my controller needed. I was sure it was the right approach to help ensure the functionality in question was working properly. But no matter what I tried, my tests didn’t work, because I wasn’t mocking it correctly. [...] I asked for help [on IRC], laying out the problem as I saw it. The first response which came back, from Ocramius, stopped me dead in my tracks: "Why are you trying to do that?"

He includes a bit of background on what he was trying to test and the functionality around it and how, when he stopped to think about it, wondered why he was testing it too. He talks about the refactor he made to his code with a positive end result - the tests now passed. He suggests a few questions to ask yourself when writing your tests such as "am I doing too much?" or "am I testing code in the right place?" Chances are, if you step back and really look at what you're testing, you might realize that the answer to these questions is just to simplify.

He finishes the post with a few suggestions, some of his own personal favorites, of places you can go for help when questions do pop up. He points out that the usual excuses shouldn't be a blocker on asking for help. He is "encouraging you to set your pride, ego and excuses aside and when you’re stuck: ask for help."

On the Zend Framework blog they're asking for your help with the project's documentation. They're looking to the users and community members around the framework to help them make the documentation more useful and stay up to date.

A piece of software is only as good as its documentation. The Zend Framework team and a dozen or so contributors are working hard to improve the Zend Framework 2 documentation, but we still want you to help us improve it even more. Any kind of help is welcome and greatly appreciated.

Most of what they're looking for is clarity - they want to ensure that what's in the manual makes sense (and is correct for the release it relates to). They're also looking for feedback on what helps you learn best - tutorials, user guides, API docs, etc. Issues and suggestions should be posted to the issue tracker in github. If you're not sure where to start, check out the contributors guide.

For anyone looking to get started helping on the Zend Framework 2 project but not sure where to begin, Robert Basic has some recommendations of places to look.

OK, here are some tips and resources so you can start helping out and contributing to Zend Framework 2.0.

Things on the list include:

• a getting started page on the ZF wiki
• Fixing unit tests on the framework
• working on the port of ZendService
• Porting patches from ZF1 to ZF2
• Check out the quickstart on github to get the ball rolling

Pablo Viquez has put together something that all of the Windows-based Zend Framework developers might find very useful during their next offline (or online, really) development session - a Windows Help file version of the Zend Framework manual.

As you might now, you can view and download the Zend Framework reference manual from the Zend Framework site and download it from the download section, however what I wanted was the Windows compiled version of it (CHM file). In order to get this version you need to compile the documentation, after running into some small issues, I manage to do it, and to save you some work.

He only had to fix an issue with one XML file to correct some escaping in the Zend_Feed_Writer.xml and zend.feed.writer.html files. You can download both the English CHM and the Spanish CHM files depending on your needs.