On the Maatwebsite Medium.com site they've posted a retrospective of their last several years of work on the Laravel Excel Open Source package.

Laravel Excel (https://github.com/Maatwebsite/Laravel-Excel) turned 4 years last November and has reached almost 6 million Packagist downloads. A good time to reflect on 4,5 years of open source development.

The article starts with a bit of history behind the initial development of the package as a simple wrapper around PHPExcel. It covers some of the initial syntax of the tool and features included from the start. The project moved on to v1.x with a complete rewrite and then into v2.x with support for the Laravel v5.x framework releases. It then talks about their "support conundrum" as they reached 1 (then, later, 6) million package downloads. They cover some of the usual project support issues, a reduction in their work on the package and how they worked to "fix it for everyone".

The post also talks about their "open source rehab" and how it changed their view from its recent "because 1 million people use it" back to making a difference in developers' lives. It finishes up talking about some of the "lessons learned" in how it worked with Laravel, a retrospective on its current state and a look forward at Laravel Excel v3.0.

On the Hackermoon site there's a new post from developer advocate Mickaël Andrieu sharing a few reasons why he thinks you should learn Symfony in 2017 if you haven't already.

In 2011, when I started my studies in computer sciences I learned the PHP using symfony 1.3, and I realized my very first student project on the beta of Symfony 2. At the time, we were moving from a fully integrated full stack framework with a back office provided to a framework that followed what was found in the Java community: besides, many components of Symfony2 were strongly inspired by JEE.

PHP 5.3 had just come out and with it the ability to start designing object-oriented correctly. [...] Large Open Source projects have started to migrate on Symfony components: if it was not first, SensioLabs has talked a lot about Drupal8 because it is one of the biggest CMS on the market. EzPublish, PHPBB, PrestaShop and many others followed, some with a full stack framework approach and others by incorporating only a few software bricks.

He then talks about the "vibrant and mature ecosystem", listing some of the packages that use Symfony components. He also looks forward to the next major iteration of the framework: Symfony Flex. He ends with his reasoning why you should learn Symfony if you haven't worked with it (or at least how it handles common things like requests and services).

The SitePoint PHP blog has made an update to their "Being a Full Stack Developer" article covering what it means to be "full stack" and various technologies that can be used (or skills to learn) to get there.

A full stack developer who can get from a prototype to full MVP (minimum viable product) is often considered a jack of all trades, master of none, and with good reason. To define the modern full stack developer, we first need to focus on what the full stack developer used to be.

The article talks about what it use to mean (back around the early 2000s) to be "full stack" and some of the things they needed to know. He then goes through the things you'll need to know now to be considered basically on the same level:

• [Basic] Server Admin / Devops
• Cloud [Services]
• Back End [Development]
• Front End [Development]
• Design
• Logging
• Mobile

He ends the post by answering the question "is it worth it" to be a full stack developer versus focused on one thing, basically boiling down to two things. First, that most devs aren't actually full stack (even if they say they are) and that it can help to have this experience to, at the least, be able to approach a wide range of projects easier.

Michelle Sanver has written up a qucik post on the Liip blog sharing a few things she thinks we can all learn from the Drupal community.

I started hearing about Drupal 8 back in 2014, how this CMS would start using Symfony components, an idea I as a PHP and Symfony developer found very cool.

That is when I got involved with Drupal, not the CMS, but the community.

I got invited to my first DrupalCon back in 2015. That was the biggest conference I have ever been to, thousands of people were there. When I entered the conference building I saw several things, one of them was that the code of conduct was very visible and printed. I also got a t-shirt that fit me really well – A rarity at most tech conferences I go to. The gender and racial diversity also seemed fairly high, I immediately felt comfortable and like I belonged – Super cool first impression.

She goes on to talk about more of her experiences at the conference, both in how it was run and about her fellow attendees. She ultimately shares the main message of the post:

[...] Embrace our differences, and each other, and accept that we do different things and we are different people and it doesn’t matter because that is what makes community work, that is what makes us awesome. Diversity matters, Drupal got this.

Matthew Weier O'Phinney, of Zend and the Zend Framework project, has put together a Storify stream of tweets he posted about some of the benefits of having multiple repositories in a project.

I've seen a number of critiques and write-ups recently about how monolithic repositories are intrinsically better for developing large projects than using a multi-repository approach. In the past year, we went the other direction, splitting our monolithic repository into individual component repositories, each with their own history, tests, and documentation. This is a summary of our experience.

He goes through a list of six different things they learned as a part of splitting up the (Zend) framework into multiple repositories instead of one monolithic one. He includes the contents of each Tweet and a paragraph or two giving it a bit more context and some examples of the changes that were involved. There's also a bit in there about changes they made to the documentation for the project as a result of these repository splits.

I'm quite happy with the switch from a monolithic repository to individual component repositories. I think our code quality is improving dramatically as a result, and I'm excited about the future of these various code bases.

The Laravel News site has a new post today about a book (from Jason Gilmore) wanting to help you learn everything you need to know about Laravel 5 - Easy Laravel 5.

Easy Laravel is a new book by W. Jason Gilmore, focusing entirely on the brand new Laravel 5. Easy Laravel features 8 chapters and over 200 pages to help you learn Laravel 5 quickly by building a real world project. Jason has spent the last 15 years using PHP, during this time he’s written seven PHP books. Including the bestseller, “Beginning PHP and MySQL, Fourth Edition”, that has been in print more than 10 years. He has a gift of explaining things clearly in a very nice style.

The post also includes some Q&A with Jason asking about why he chose to write a book on Laravel, what was the most enjoyable part of the process and what his favorite new feature is. The remainder of the post walks you through the chapters of the book and introduces you to some of the content with a brief summary of each.

In a new post to his site Ben Ramsey shares a few suggestions around things to ask and do to learn a new codebase (whether that means in a new job or coming into a new open source project).

A few days ago, my friend Ed Finkler started a new job. Earlier this week, he posted on Twitter: "First days humble us all." Having begun a new job myself, I shared Ed’s sentiment. Last weekend, while at the Madison PHP Conference, we were discussing what developers can do during the interview process to get an idea of the kind of codebase a company has.

He includes a few questions for developers to ask, either during the interview or once hired, about the codebase itself including:

• what coding standards the company follows
• how much of the code is covered by tests
• have the company’s deployment process described

He also recommends learning the codebase by diving in and either writing tests for untested areas or work through bug reports and fix (then test) them.

In the /r/PHP community on Reddit there's a discussion going on about the best way to learn PHP. The op wonders:

Now a days there are numerous PHP Framework popping out and being fully supported, just to put it straight. Should i jump on one of those like CI, etc. and forget about doing a native code? I'm a new in PHP and now i'm confused which to choose.

There's lots of good answers to the questions with people leaning both ways. Suggestions include:

• "The answer is that you should do both raw php programming as well as get familiar with frameworks. This might sound like a copout, but it's really not."
• "I would agree with the others that it's best to learn the basics of PHP first. Understand PHP and its various constructs, particularly if you're a new programmer."
• "PHP frameworks ARE PHP. [...] Regardless, frameworks are generally pretty advanced PHP, and may be hard to get into without a good grounding in PHP generally, and OOP specifically."
• "Learn PHP. You might be able to make a site if all you do is focus on a particular framework, but by focusing on learning to use the language itself you'll be able to switch from one framework to another. "
• "If you don't have at least some understanding of the basics, learning a framework to start off it a bit of overkill and may or may not actually help you much. I think it's hard to appreciate what a good framework does for you if you don't have a fair understanding of how things are often done without one."

Have some thoughts of your own? Check out the full post and share them!

In his latest post Jani Hartikainen makes a recommendation for those wanting to become better developers: first become a teacher. He suggests that communication is the second most important skill a developer can have.

What is the most important skill for a developer besides actually writing code? Communication. What do you typically do when you communicate as a developer with someone else? You explain problems, you describe solutions, you talk to non-programmers about what you’re doing. You could also say that you’re teaching others about what you’re doing. [...] Being a good communicator is often completely overlooked.

He looks at why it's important for a developer to have good communication skills and what it means to "communicate well" with fellow developers. He suggests that real teaching can start when developers understand the domain and code they're working with. He also talks about the flip side of things, the importance of listening to other developers and those trying to help. Listening well means understanding the question and being open to different ideas, even if they contradict your own.

As with all aspects of programming, the best way to improve communication and your ability to reason about code on a higher level is practice.

In his latest post Brandon Savage follows up his previous post (about learning the language first) that points out that frameworks are important/useful but they shouldn't be the focus.

In writing about how the framework you learn doesn’t matter, I hoped to advance a position that articulated the fact that among the many frameworks, picking the right one is less important than getting a solid grasp on the underlying language. In fact, frameworks have tremendous advantages to them. They take care of a great deal of things for us, things that most applications need and nobody wants to write every time they need it. Frameworks are tremendously helpful.

He points out that learning a framework first and depending on it for common functions limits your skills and hinders you from the power of the language (PHP) itself. He suggests that it's not a "language or framework" debate, but more of a "language then framework" perspective.