Tomas Votruba has put together a new post with a list of five helpful hints for working with GitHub in your development projects.

The best programmers aren't the smartest in the field. They're lazy, they know their tools well and they know good tools other programmers don't.

Do you know the following tips?

His tips include using single-character console command aliases, receiving notifications only when a new package release is made, and the use of the refined-github browser (Chrome/FireFox/Opera) to help reduce required clicks. He also shows how to implement Composer "scripts" for use on the command line - a very useful extension to your Composer configuration.5 Tips to Effective Work with Github Repository

Sometimes it's just fun to talk about all of the odd things we've done with PHP in the past. In this thread on /r/php on Reddit, developers have shared some of the "weirdest programs" they've created with the language. Here's just a sampling:

• a script which automatically wish for friend's birthday on midnight in facebook using Graph API
• a page counter
• a video watermarking and streaming tool
• a counter-bot script for preventing bot spam accounts in a game
• generate Flash SWF files
• a pulling an image from a webcam for a "real-time" Facebook cover photo
• solving quadratic equations for homework
• a "cat fax" service
• a Quake game browser

There's many, many, many more in the full post and it's interesting to see what all other developers have done. Head on over and share your weirdest PHP scripts too!

Scraping content from other sites (while slightly controversial) can be a helpful way to pull information into your application without the overhead of manual interaction. In this new post to his site Sameer Borate shows how to use a DOM parser to extract data from a remote site.

In this post I have explained some elements to scrap data from external websites. Simple HTML DOM parser is a PHP 5+ class which is useful to manipulate HTML elements. This class can work with both valid HTML and HTML pages that do not pass W3C validation. You can find elements by ids, classes, tags and many more. You can also add, delete or alter DOM elements. The only one thing you should care about is memory leaks – but you can avoid memory leaks as explained later.

He starts by walking through some of the basics of creating a new instance of the class and loading the content (either as a string or as a file) to be parsed. He then give several examples of how to query the contents of the document and locate multiple or single elements (including the use of CSS-type selectors for fuzzy attribute matching). He finishes out the post showing how to access element attributes and append content back to the original HTML.

Ben Sampson has posted a quick guide on his site sharing a deployment script for Laravel applications he's found useful.

A good deploy script can save you time and speed up your application, and it only takes a few minutes to set one up.

I have a standard deploy script which I use for almost all of my projects, which I'm going to break down and share with you.

Note: This article assumes that you're using Laravel Forge. If you're not, many of the settings will be applicable, but the setup steps may be a bit different.

He starts with a brief description of what a deployment script is and goes through the functionality he has included in his:

• switching the site to maintenance mode
• clearing caches
• clearing and optimizing routes
• clearing and optimizing the configuration
• clearing expired password reset tokens
• compiling front-end assets

He puts it all together into a single file that's then included in the Forge deployment process. He doesn't provide other instruction as to how to use this script with another deployment method but it can potentially be used anywhere a bash script could.

Anna Filina has a quick post to her site with some recommendations around testing legacy PHP scripts giving an example of a challenge to test a controller in isolation from the rest of the application.

I gave myself a challenge: to test a legacy "controller" in isolation, yet with minimal impact on the original code.

She starts with the example code she'll be testing and then works through the steps to effectively test it:

• isolating it from the other functionality in the application
• mocking a statically called method
• requiring necessary files
• executing the controller under test

The post ends with the test class she created showing how to evaluate the result of a call with one invoice in the billing system. She makes one comment at the end to answer the question "why not just refactor" but points out that, especially in larger legacy applications, that's just not always an option.

On the Forma-Pro.com blog there's a new post from Maskim (their Chief Architect) comparing PHP AMPQ libraries including some benchmarks of their performance of their handling of messages.

Increasing popularity of AMQP interop prompted a wave of questions regarding which adapter is the fastest. In this post, I am going to share my findings of message publishing performance. There will be a similar post about consumption side.

He compares three of the main libraries: php-amqplib, amqp-ext and bunny (as well as their adapters for interoperability). To get a good comparison he's also thrown in one written in Golang for external comparison. He start be outlining the system specs he used for testing and then various graphs of the benchmark results. The results of his benchmark script are interesting with only a few oddities here and there. The post finishes with a summation of the results but you'll have to head over there to see those results.

Rob Allen has a quick new post with a handy script you can use to auto-complete Composer script names on the command line (for bash).

As I add more and more of my own script targets to my composer.json files, I find that it would be helpful to have tab autocomplete in bash. I asked on Twitter and didn't get an immediate solution and as I had already done something similar for Phing, I rolled up my sleeves and wrote my own.

He created the bash completion file where Bash could locate it (a special "bash_completion.d" directory). He includes the code you'll need to have in the bash script and briefly explains how each line works. He also includes an example of the output showing how the script catches both the built-in and custom commands as auto-complete options.

On the SitePoint PHP blog editor Bruno Skvorc has a new tutorial posted showing a possible way to "fight recruiting spam" in your inbox with the help of a little bit of PHP.

The biggest concern I have with modern email providers, is the fact that they are all quite bad at spam control. [...] I don’t mean the “Nigerian prince” type of spam, which is mostly blocked successfully (unless you’re using FastMail – they can’t even recognize those) but stuff that I’m really, really not interested in getting. Case in point, recruiter spam.

In this tutorial, we’ll get started with building a custom email processor which can read individual emails, run them through some predefined rules, and act on them. The end result will be very similar to what many providers offer out of the box, but it’ll lay the groundwork for more advanced aspects in future posts.

His example application will do things like: do keyword matching for recruiter-ish things and auto-reply (then delete the original) and purge emails sent after unsubscribing from the service. He builds out the example application on a Homestead Improved VM, coming pre-installed with the IMAP extension for PHP (used to access the user's inbox). He then installs the tedivm/fetch package for the PHP code and shows how to read the emails from your inbox. He uses the FastMail service so he walks through how to hook the script into that service using an "application password".

From there he develops the functionality of the application including:

• pattern matching on the body contents for "recruiter-ish" terms
• setting a "points" threshold for the number of matches
• sending replies with Swiftmailer
• whitelisting certain terms
• moving the messages into an "auto-replied" folder so we know who the script talked to

All of the code you'll need is included in the post along with several screenshots that help to ensure you're on the right path.

In this post to his site Jelle Raaijmakers dives into a script that's commonly injected into vulnerable sites and used by spammers to send messages without the knowledge of the site owner.

Let’s take a look at a PHP script used to send spam. These types of scripts run on servers all over the world and might give you some insight into a spammer’s dedication to annoy the hell out of you. Spammers abuse known flaws in unsecured websites and applications to break into a server and install scripts that are able to send loads of spam.

[...] Everyone running a mildly popular WordPress site knows that exploits can be really easily introduced by installing plugins from a less than reputable source – or by not keeping your plugins up to date. Sometimes, a zero-day exploit for a popular WordPress plugins becomes known and thousands of installations worldwide are infected at once.

He then goes through a script he found in an infected WordPress instance of his own on a shared hosting provider. He talks about what these kinds of scripts usually look like (an encoded eval injected into current scripts) and the process he followed to dissect it:

• Step 1: determine method of obfuscation
• Step 2: introduce newlines
• Step 3: replace the $j10 values
• Step 4: concatenate constant strings
• Step 5: replace function invocations
• Step 6: prettify the PHP code
• Step 7: remove default $j10 argument
• Step 8: decode the $pate payload
• Step 9: replace $_POST references
• Step 10: map function and variable names

It's not a super simple process, but in the end he's left with the complete PHP script that loads a remotely defined configuration, tries to send the emails and even retries if there's a failure. He includes a few noteworthy things about the script including STMP connection auto-detection and DNS lookups over UDP.

Rob Allen has a post to his site talking about using Composer with shared hosting, showing how to use this popular tool even if you're on a shared hosting environment and don't have direct SSH or shell access.

I've seen this sentiment a few times now, so this seems like a good time to point out that you do not need SSH access to your server in order to use Composer. In fact, I don't run Composer on a live server (regardless of whether it's using shared hosting) and it's not on my list of things to do in the near future.

What you do need is a process where you handle your Composer dependencies on your own computer where you have PHP running.

He gives two possible solutions to the problem: either commit your dependencies or create some kind of build script that can execute the Composer install for you on deploy. He gives details on both of these solutions including the process for installing the dependencies with an automated FTP script (run at deploy rather than committed).