On the Programming Are Hard site there's a recent post looking at PHP application structure and how they handled the structure of one of their applications.

One of the biggest struggles for me, as an app developer, is coming up with an architecture that I'm happy with. It's something I wish other developers talked about more often. I thoroughly enjoyed Kris Wallsmith's SymfonyCon talk. It's very raw and real and doesn't come across as him talking down to anyone at all. Do I agree with everything he says? No, but that's not a bad thing. It's very insightful and I really enjoy taking a peak behind the curtains and seeing how other people do things. This is my attempt at doing just that.

He's broken down the structure into the overall parts and provided examples and summaries of each:

• The use of packages
• Entities
• Events and Event Listeners
• Commands and Handlers
• Exceptions
• Providers
• Repositories
• Security functionality
• Services
• Testing
• Validation
• Value Objects

Each section includes sample code and a description of where in the overall directory structure it fits. The setup is largely based on a Symfony application but it can be extracted (since it's mostly concepts) to most frameworks out there, even custom ones.

Michael Dyrynda has a recent post about handling matching and limiting results in Eloquent models in a Larvel-based application.

Say you have a users table with the following fields in it name, email, city, state, zip. You may want to provide fuzzy searching for the name, email, or city and exact matching for the state and zipfields. Why fuzzy matching for only some of the fields? Well, you might want to search for everyone whose name contains Michael or has has an @gmail.com address. Be mindful of the latter; it will expose a large dataset if you're not careful in restricting access to the functionality. You probably wouldn't want to allow it in anything bigger than a proof of concept (which this is!).

He goes through the model process, showing how to set up a simple model with the fields mentioned and make use of query scopes to limit returned results. Code is included showing how to define the "scopeFilter" method in the model and call the "User" model instance with the "filter" method. The example limits the results to only the users with a value in the "name" and "state" field.

Stefan Koopmanschap has a new post today talking about code reviews and introducing the concept for those not familiar with what they are or their usefulness.

Code reviewing is exactly what it sounds like: It is reviewing code written by another developer. There are different ways of doing this, but in the end it all comes down to having at least one other set of eyes checking any code written before it is released. There's many reasons for doing code reviews. It can be to prevent security issues, to ensure correct performance of your application, to prevent bugs but eventually it all comes down to the more generic term of ensuring the quality of your application.

He goes on to talk about some of the most common ways to do code reviews, either in something a simple as a pull request out to face-to-face discussions as the code is being introduced. He includes some hints on preparing for the review, steps to perform the review, dealing constructively with the comments made and finally the approval. He talks about who should do the reviewing and how they can still be useful even if you work alone or with a QA department.

• Voices of the ElePHPant: Interview with Larry Garfield
• Laravel News: Homestead Now With Blackfire Support
• Snack Overflow: Unit testing static calls without refactoring the world in php
• Site News: Popular Posts for the Week of 02.27.2015
• Community News: Latest PEAR Releases for 03.02.2015
• Community News: Gophp7-ext Project
• Derick Rethans: Xdebug 2.3: Moar var_dump()
• Matthew Setter: Can VIM Ever Replace PHPStorm?
• SitePoint PHP Blog: Best PHP Framework 2015 Survey
• Community News: "Are Conference Talks Getting Too Soft?" (Adam Culp & Cal Evans)

On the NetTuts.com site there's a new post talking about protecting your keys when using a public site like GitHub. This relates to an easy thing to forget - removing hard-coded credentials from code before pushing it public.

In December 2014, Slashdot ran an alarming story Bots Scanning GitHub To Steal Amazon EC2 Keys, based on developer and blogger Andrew Hoffman's experience trying out Ruby on Rails on Amazon with AWS S3. He inadvertently committed an application.yml file with his AWS keys. [...] It's an easy mistake and most of us have probably done a similar thing at one point or another. And it's not just AWS keys that are at risk. As our use of cloud-based services increases, the expanding use of a broad variety of service API keys can be leveraged by hackers and spammers alike.

He goes through a solution he's found to help protect those credentials, in this case working with the configuration of a Yii framework-based application. He starts with a mention of .gitignore but points out that it could have unexpected results from "quirks" in its handling. He suggests a different option - using a configuration file that lives someplace outside of the main git directory and can be referenced directly from inside the application. He provides two kinds of examples: one using a PHP-based configuration and another based on an INI file. He finishes the post with a mention about WordPress plugins and the fact that they're (usually) stored in a database and open to exposure if a SQL injection vulnerability is found.

The SitePoint PHP blog has started off a new series this morning to help you create a custom Laravel application based on the 500px photo community site. In this first part of the series they help you get the application up and running and connected to the 500px API.

500px is a photo community for discovering, sharing, buying and selling inspiring photography. In this article we are going to explore their API and build a small showcase app. Let's get started.

You'll need to have Laravel set up and working to get started on the tutorial, but they help you get the other libraries installed and configured (like Guzzle). They start with getting a list of the most popular photos from the API, connecting it to your account via an OAuth token. A base route is created and connected to a controller/action with a view to render each of the photos in their own divs. They then add in a bit of Javascript to create a "Load More" button that makes another call, with pagination, to pull in more photo details. Finally they show you how to create the user profile page, grabbing user information and related photos and rendering them out to a page.

Paul Jones has posted about a new tool he's worked up specifically for authors looking to write using Markdown and wanting it to generate out like DocBook results. His tool, Bookdown, uses Markdown and JSON files instead of XML configurations.

Yes, I know, there's a ton of static site generators for PHP out there already [...but they're] not DocBook-like documentation. By "DocBook-like", I mean (among other things) numbered headers, auto-generated tables-of-contents on their own pages, hierarchical multi-page presentation, and the next/previous/up linking at the top and bottom of pages.

[...] So: Bookdown. This scratches my particular itch, with very few dependencies. Bookdown, although it can be used as a site generator, is only incidentally a site generator. What it really is is a page generator, with the idea that you can integrate the pages into any other site you want.

The library is separate from the project and is written to use a dependency injection methodology to keep things decoupled and well-structured. If this sounds interesting either for personal use or if you'd like to check out the code, head over to the project site for more information.

The Laracasts site has launched a new video series with some advanced tips on using Eloquent, the ORM layer from the Laravel framework.

Sure, you've learned the essentials of using Eloquent in your applications, but do you really understand what's going on under the hood? Well, that's specifically what we're interested in for this series. How do all the bits and pieces fit together?

There's two videos posted so far helping you build a basic application to work inside of and looking behind the scenes of "find" to see what happens when it's executed. Only the first video in the series is free, but it gives you an idea of what will be covered and the style of the videos.

• Community News: Packagist Latest Releases for 03.05.2014
• Coding the Architecture: Five things every developer should know about software architecture
• Simon Holywell: HHVM vs Zephir vs PHP: The showdown
• Master Zend Framework: Make Module Configs Cacheable with the ZF2 Factory Interface
• VG Tech: Swagger Docs in ZF2 with Examples - Part 2: Swagger UI
• MakeUseOf: Create The Perfect PHP Development Environment In Android
• Ross Tuck: Persisting Value Objects in Doctrine
• Lorna Mitchell: Working with PHP and Beanstalkd
• SitePoint PHP Blog: Installing PHP Extensions on Nitrous.io
• Gonzalo Ayuso: Auto injecting dependencies in PHP objects
• Community News: Latest PEAR Releases for 03.03.2014
• PHP Town Hall: Episode 20: A Nice Friendly Chat About Sculpin, Guzzle and PSR-7
• SitePoint PHP Blog: Simple Captchas with PHP and GD
• ServerGrove Blog: Symfony2 components overview: Validator
• Dougal Campbell: mysql vs mysqli in WordPress

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.