In a new post to his site Junior Grossi shares some of his thoughts about Open Source and how it's less about "free software" and more about sharing and giving back.

Maintaining an open source project – even a small one – is not an easy task. The open source ecosystem is about sharing and contributing, about giving and receiving. You scratch my back and I will scratch yours.

He suggests that working in Open Source is less about the actual software that's being written as it is a lifestyle. For him, the goal is to make someone else's life better by working on something you're sharing (instead of working on something commercial). He includes a quote from Fabien Potencier (of Symfony) about Open Source developers being exploited for their free software and how, despite the gift of time and work spent on the code, some people don't appreciate the work and just complain.

Instead of complaining about features or bugfixes, do it yourself, and show your gratitude for people that spent their free time working on something to help your life. They could be with their family but no, they were doing open-source. And you should thank them for that.

He finishes with a few thoughts about giving back to the projects you use and enjoy. It doesn't always have to be about code too - you can submit bugs, contribute to documentation or even just write up a tutorial to share your own knowledge of using the package.

Phillip Shipley has written up a post for his site walking you through the process of using PHP to read from and write to Google Sheets via the Google Sheets API.

This past week I needed to be able to read some data from a Google Sheet and then update a column for each row after processing it. This sort of thing should be simple, Google is built on APIs and has client SDKs for just about every language. I’ve also integrated with several Google Admin APIs previously so I expected this to be a breeze. I was wrong.

I started out by reading the Quickstart for Sheets API with the PHP Client, but almost immediately I could tell it was not written for my use case. [...] My use case is to use a backend process to function as a service account and batch process data. So the whole API credentials process was wrong for me.

He tried a few different approaches and finally, after some guessing, discovered how to share a sheet with the email address for the application. He then includes the steps to follow to get this same setup configured for your application and the code (using the Google_Client) to read and write to the sheet.

The TutsPlus.com site has posted the latest in their "Programming with Yii2" series of tutorials with this new article looking at features for the application useful to build community around the site.

In today's tutorial, I'm going to show you how to extend Yii to easily mimic a site like Reddit with voting, comments, and sharing.

[...] I built some my latest Twitter API episodes on the early version of this platform, following friends on behalf of users and analyzing our followers. The site I described in those, Twixxr, forms the foundation of my Yii customization work.

So adding core functionality like voting, comments and sharing makes so much sense. As you expand your Yii codebase with these kinds of features, building new sites becomes faster, easier and increasingly powerful.

He then spends the rest of the article showing how to use three Yii2 plugins to help provide the community functionality he needed: a voting extension, a plugin for integrating Disquis and a "social extension" for other social plugins and widgets. He shows how to get these extensions installed and what code updates you'll need to make to use them across the application. This also includes screenshots of the results so you can be sure that you're on the right track.

On the Laravel News site there's a recent post by Sharon Steed talking about building a culture of trust and why sharing is good on both a personal and corporate level for your career (and not just in technology).

I speak about empathy on teams and why vulnerability is a great asset in your professional life. Sharing ideas falls right in line with my own ideology, but I also understand why people are so terrified to offer up opinions.

[...] I’m constantly amazed at how many people refuse to talk about projects they are working on for fear of others trying to swipe the idea. I’m even more so surprised at people who go out of their way to not share ideas with bosses or coworkers. Yes, there is absolutely a chance that someone else will take credit for that idea. The nature of working with other people, however, is that of collaboration.

She goes on to give some example situations, how sharing and trust between people plays and role and how many are realizing the value of being open. She gives examples of companies that are following this same idea on a corporate level like Buffer, Zappos and Landmark (an oil and gas software company). She ends the post with some practical advice on how you can help foster this culture of trust in your own company and career.

In a post to his site Gonzalo Ayuso shows you how to combine authentication between Socket.io and a PHP frontend running a simple Silex-based application.

Normally, when I work with websockets, my stack is a socket.io server and a Silex frontend. Protect a PHP frontend with one kind of authentication of another is pretty straightforward. But if we want to use websockets, we need to set up another server and if we protect our frontend we need to protect our websocket server too.

If our frontend is node too (express for example), sharing authentication is more easy but at this time we we want to use two different servers (a node server and a PHP server). I’ve written about it too but today we`ll see another solution.

He sets up a simple Silex application with three routes - the root (/), a login route and a "private" one requiring a user to be logged in. This last route makes the connection to the websocket server in the template. This connection sends the current session ID to the backend where it's verified with a simple Socket.io middleware. Sometimes the session ID cookie will be set as HttpOnly so he provides an alternative for that: a new endpoint just for getting the current session ID for the websocket request.

The Vegatbit.com site has posted a tutorial today showing you how to build a link sharing site with Laravel, a simple application that lets you create "shortlinks" to make it easier to pass along URLs to others.

Building your own applications, even on a simple or small scale, is a great way to build your skills. This Link Sharing Website tutorial using Laravel will help us to to just that. If you’d like to save yourself a little time, you could just as easily head on over to http://www.easylaravelbook.com/ and pick up a great pre written application, PHPLeaks. PHPLeaks is a Link Sharing Website that has everything you need to get a nice starter project going.

They walk you through every step of the process, showing you all the code and commands you'll need to get the application, database and frontend set up and running. This even includes the installation of the Homestead virtual machine and configuration of your local machine. Don't be intimidated by the long list of steps - it's pretty quick thanks to several of the Laravel artisan commands.

On the Graze.com Tech blog there's a recent post about sharing logic between controllers with the help of traits. He makes use of the traits functionality in PHP to abstract out functionality common to multiple controllers (in his case, common user functionality).

There have been a few times I have come across a situation where I need to share some logic between controllers but it hasn't been as clear cut as abstracting that logic out into a library. I've been pondering the best way to tackle this problem and would like to share my thoughts.

In his example he shows how two different controllers, the Account and Signup controllers, both need to be able to look up an address and perform some simple checks on the results. The logic is duplicated so he first tries to move it out to an abstract controller but notes that it's not the most ideal solution. Next he tries moving the code out into a library but finds issues with separating out the necessary concerns. Finally he moves the logic into a trait (AddAddressTrait) that contains it and allows the direct integration of his "lookupPostalCode" method into the controller without inheritance or other design issues.

Gonzalo Ayuso has a new post that responds to the idea that "singletons are a problem when testing" your applications with something like PHPUnit.

Maybe this pattern is not as useful as it is in J2EE world. With PHP everything dies within each request, so we cannot persist our instances between requests (without any persistent mechanism such as databases, memcached or external servers). But at least in PHP we can share the same instance, with this pattern, in our script.

He illustrates a bad side effect of this sharing of resources with a simple unit test that increments a counter in a class. He notes that, because the script shares the object, you can't reliably know the state of it as you don't know what's happened before your use. He recommends two things to help the situation - either not use them at all or destroy the instance each time after using it (counterproductive to using a Singleton, obviously).

On the NetTuts.com site there's a new tutorial introducing you to one of the relatively new players to the PHP framework scene - Laravel. In this article you'll see how to set up and create a basic Laravel app - a simple social app for sharing photos.

In this Nettuts+ mini-series, we’ll build a web application from scratch, while diving into a great new PHP framework that’s rapidly picking up steam, called Laravel - a simple and elegant PHP 5.3 framework. First up, we’ll learn more about Laravel, and why it’s such a great choice for your next PHP-based web application.

They briefly introduce the framework and talk about some of the things that it offers for the PHP 5.3 users out there (including the use of packages called Bundles, the built-in ORM, migration and Redis support). They start you off on the road to building the sample application with instructions on downloading, configuring and creating the first controllers, templated views (with Blade) and a bit on asset management.

Henri Bergius has a new post to his blog today about a tool that could help make code reuse across PHP applications a much simpler process. The Composer tool (and Packagist) make setting up packages and dependencies easy.

In PHP we've had a lousy culture of code-sharing. Because depending on code from others as been tricky, every major PHP application or framework has practically had to reimplement the whole world. Only some tools, like PHPUnit, have managed to break over this barrier and become de-facto standards across project boundaries. But for the rest: just write it yourself. But now Composer, and its repository counterpart Packagist, promise to change all that. And obviously new conventions like PHP's namespacing support and the PSR-0 standard autoloader help.

Making a package is as simple as setting up a JSON-based configuration file that names dependencies and package metadata (like name, type, etc). Composer generates an autoloader of its own to handle the loading of your needs based on the dependencies listed as a part of the package. If you'd like more information about Composer or to get the latest version and try it yourself, check out the project's github repository.