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.

In this new post Mike Bronner shows you how to get the latest PHP5 and Mcrypt versions installed on OS X Yosemite to make ti easier on developers needing to run commands outside of Homestead.

Laravel Homestead has brought virtual machines for web development to the mainstream PHP developer: it makes setting up a development stack similar to XAMP extremely simple. [...] However, one of the drawbacks so far has been that you always needed to run Laravel Artisan commands from within homestead, as they depending on MCrypt being installed. [...] The accepted solution thus far has been to install newer versions of PHP alongside Apple's version using Homebrew or MacPorts. [...] However, there's another method I came across while research some non-related issues: install the latest version of PHP from a binary that includes the MCrypt extension.

He walks you through the complete process (well, except for getting Homestead - that needs to already be there) complete with each command you'll need. You'll need to be familiar with the command line to make this all happen and know how to edit configuration files. If all goes well, the "artisan" command will work correctly and no errors will happen during the compile. He also includes a fix you'll need to put in to get the database configuration working from outside Homestead too.

Evert Pot has written up a new post today with some of his thoughts about what's wrong with the PSR-7 proposal in the PHP-FIG. PSR-7 relates to a standardized interface for HTTP request and response handling.

PSR-7 is pretty close to completion. PSR-7 is a new 'PHP standard recommendation', put out by the PHP-FIG group, of which I'm a member of. [...] PSR-7 gets a lot of things right, and is very close to nailing the abstract data model behind HTTP, better than many other implementations in many programming languages.

But it's not perfect. I've been pretty vocal about a few issues I have with the approach. Most of this has fallen on deaf ears. I accept that I might be a minority in feeling these are problems, but I feel compelled to share my issues here anyway. Perhaps as a last attempt to sollicit change, or maybe just to get it off my chest.

He breaks up his thoughts into a few different categories, each with a summary and sometimes some code to help make his point a bit more clear. He talks about immutability, how objects will be immutable and shows an example of change in how Silex would have to function to follow the standard (with before/after). He then goes on to talk about the "issue with streams" and how the current proposal could allow for changing of the incoming request into a new one with new headers...not immutable. He ends the post talking about PSR-7's stance on buffering responses and how, even if his project doesn't adopt the PSR in the strictest sense, they may still take some inspiration from it.

• Convert PHP Warnings and notices into fatal errors | Rob Allen #phpquickfix, #convert, #warning, #notice, #fatal, #error
  
  
• Zend Certification Study Guide 3rd Edition Published, and a new Book on the way! | Davey Shafik #phpquickfix, #zend, #certification, #guide, #3rdedition, #published
  
  
• Modern Defense Against CSRF Attacks - Resonant Core Blog #phpquickfix, #csrf, #threatmodel, #library, #anticsrf
  
  
• Laravel 5 Generators - Laravel News #phpquickfix, #laravel5, #generator, #package, #migration
  
  
• Watch RFC Votes, live, as an event stream : PHP #phpquickfix, #rfc, #votes, #realtime, #stream
  
  
• Error Handling in PHP - Nomad PHP #phpquickfix, #error, #handling, #nomadphp, #video, #ianlittman
  
  
• Three things we know about Laravel 5.1 - Laravel News #phpquickfix, #laravel5, #jobs, #psr2, #envoy, #ssh
  
  
• Keeping the Code Monkey Fit - Nomad PHP #phpquickfix, #codemonkey, #fitness, #nomadphp, #video
  
  
• Add Laravel 5 module files by janhenkgerritsen · Pull Request #1704 · Codeception/Codeception #phpquickfix, #codeception, #testing, #laravel5, #support
  
  
• Cachet: A status page system built on Laravel - The Changelog #phpquickfix, #cachet, #status, #page, #laravel
  
  

There's an interesting set of posts from PHP community members Adam Culp and Cal Evans each on a similar subject centering around conferences and the presentations made at them. They both wonder if talks are getting too "soft" and not focusing as much on the technology and getting in-depth as they should be. From Cal:

PHP conferences are changing very slowly, and not in a way that I like. I blame myself. As a frequent speaker I am getting lazy. I get caught up in the excitement of the CfP, I write up 5-10 abstracts and shotgun them into the CfP system hoping that something hits the mark. I've not actually written these talks. In most cases, I'm pretty sure I can get 45 minutes on the topic, but I don't know for sure because I've not bothered to write it yet. Adam Culp talks about this very thing in his post "Are Conference Talks Getting Too Soft?".

Adam points out that, while introductory talks and overviews are acceptable level coverage for someone new to the speaking scene (or development), the trend seems to be that everyone is providing less "meat" in their talks.

It is hard to teach a great amount in a 1 hour talk, but if there is not some immediately usable content an attendee will have a tough time proving to their short sighted boss that it was worth their time.

Both Adam and Cal set out a challenge, both to themselves and other speakers in the community. They encourage you to spend more time with your subjects, get in-depth into the topics, present on what you're excited about and maybe even try them out locally first.