On the TutsPlus.com site Jeff Reifman has posted the latest article in his "Building with the Twitter API" series. In this latest tutorial he shows how, with the Yii2 application they've been building, to analyze your followers and get information like followers, tweets, favorites, etc.

Welcome to the latest episode of our Twitter API series. In our last episode, I built Twixxr.com which will let you discover influential women on Twitter for your account to follow. Today, I'm going to turn the focus inward to look at my own followers.

[...] For a long time I've wanted to look more closely at my Twitter followers and answer some questions: Who exactly is following me? And why aren't they more interactive? Is it possible that only 10% of my followers are real people? [...] The Twitter API is a good tool to investigate this. Yet it has a ton of rate limits which make even something simple like analyzing your followers quite complex. In today's episode, I'll show you how I worked with the rate limits to assess and build a scoreboard of my followers.

He starts with a screenshot of the ultimate result of gathering the information for each follower from the API and describes what the overall goals are. From there's it's all about the code:

• creating database migrations for the related tables
• making the connection to the Twitter API to gather follower data
• saving the data to the database
• creating the "score" for each based on if the account is verified, protected, and follower/friend count

The post ends with the code to show the "scoreboard" presented in the original screenshot having all of the information populated for his follower set.

The SitePoint PHP blog has a tutorial posted by Patrick van Bergen showing you how to analyze the world using a combination of PHP and the data from the GDelt (Global Database of Events, Language and Tone) database.

Are you interested in political world events? Do you want to play with one of the world’s largest databases? If you answered either of those questions with a yes, keep reading – this will interest you! This article follows up on the promise to use GDELT with PHP.

I will show you a simple example of how to use GDELT through BigQuery with PHP, and how to visualize the results on a web page. Along the way, I will tell you some more about GDELT.

He starts by briefly introducing the GDelt service, what kind of data it contains and how to make some sample queries with their BigQuery dashboard. He then moves more into the code, talking about some of the basic concepts of the data and setting up an account you can use for your queries. The example code uses the Google Cloud library to access the API and execute the query. Included are examples of querying metadata, the different datasets available and some visualization examples.

On the SitePoint PHP blog there's a tutorial posted showing how to optimize your MySQL handling with the help of the Beaver query logger package and the details it provides.

Clients with an existing application sometimes ask me to fix bugs, improve efficiency by speeding up the application, or add a new feature to some existing software. The first stage of this is researching the original code – so-called reverse engineering. With SQL databases, it is not always immediately obvious which SQL queries MySQL executed – especially if these queries were generated by a framework or some kind of external library. In this article, I will talk specifically about MySQL and present a common optimization use case which might come in handy if you run into a similar problem one day.

He shows how to update your MySQL installation to log all queries out to the log location of your choice. This log can then, in turn, be parsed by the Beaver package and provide details about what's happening in the query and where it could be optimized. The article also provides a more "real world" example of a query happening in a Yii2 application resulting in a large number of queries being generated. He shows how to update the query handling to make the loading more efficient (through joins rather than individual queries) and what the resulting statement looked like.

QaFoo has posted an announcement to their blog about a new tool they're offering to help developers better visualize the quality of their PHP code with a new visualization tool, the Quality Analyzer.

In code reviews we often browse metrics, source code and reported code issues together with our customers. This leads to discussions about the current state of the code and possible improvements. First we used a bunch of shells scripts for that. In a second step we developed a simple PHP (Open Source) application helping us to do the job. Now we did the third step and rewrote that application into a React based client side (Open Source) application.

They start with an overview of why they created the tool (an evolution of the older Code Review tool) and why it was split into a frontend/backend model to provide easier pipeline integration. They then introduce the functionality in the new tool, based on a D3.js interface. A few screenshots of the interface are also included to give you an idea of how it reports its findings and the dashboard providing an overview of the findings. You can try it out by grabbing it from the project's GitHub repository.

Gareth Heyes has pointed out an interesting tool today for analyzing the source of your application and trying to discover security-related issues: RIPS

RIPS is a tool written in PHP to find vulnerabilities in PHP applications using static code analysis. By tokenizing and parsing all source code files RIPS is able to transform PHP source code into a program model and to detect sensitive sinks (potentially vulnerable functions) that can be tainted by userinput (influenced by a malicious user) during the program flow. Besides the structured output of found vulnerabilities RIPS also offers an integrated code audit framework for further manual analysis.

The project site lists out the features that come with the tool, what it searches for (including command execution issues, header injection, file manipulation and SQL injection) and some example screenshots of its interface. You can download the latest version and try it out for yourself.

In a new post to his blog Sebastian Bergmann takes a quick look at using a static analyzer, clang and scan-build, to analyze the PHP interpreter (specifically during the compile process).

I have been tinkering with CLANG's static analyzer lately. This post summarizes how I installed LLVM and CLANG and performed the analysis of a build of the PHP interpreter.

He includes all the commands (unix-based) to get the clang tools/libraries installed in the correct places as well as what to add to your $PATH to get the "scan-build" command to work with the make and make install parts of the PHP compile process.

Johannes Schlüter has a new post to his blog today mentioning the beta release of the mysqlnd_ms plugin (previously mentioned by Ulf Wendel and a new feature that can be plugged into the MySQL Enterprise Monitor to make the Query Analyzer directly use PHP instead.

When running a PHP-based application with MySQL it is often quite interesting to see what actually happens on the database sever. Besides monitoring of the system load etc. it is often interesting to see what queries are actually executed and which of them are expensive. A part of MySQL Enterprise Monitor is the MySQL Query Analyzer which helps answering these questions.

This was handled via a proxy that sat between the database and app server and ran through the queries looking for improvements. This new plugin keeps it closer to PHP itself without having to hit against the proxy. You can see the result in these two screenshots from inside the Manager application. You also have the side benefit of getting a stack trace of it running through the app to help you identify the spots most needing improvement in the code too.

Sebastian Bergmann has a new post to his blog talking about some of the future plans for better code coverage metrics for PHP applications (not just the statistics that we have now as generated from PHPUnit runs combined with Code_Coverage PEAR package and Xdebug).

Xdebug currently only supports what is usually referred to as Line Coverage. This software metric measures whether each executable line was executed. Based on the line coverage information provided by Xdebug, PHP_CodeCoverage also calculates the Function / Method Coverage software metric that measures whether each function or method has been invoked.

The various kinds of coverage they're planning the in future include statement coverage, branch coverage (boolean evaluation), call coverage, path coverage with an alternative of linear code sequence and jump coverage (LCSAJ).

On the Web Development Blog today there's a new post about 404 pages and some of the things you can do to make them a bit more useful than just a "not found" message.

After your websites getting more pages and links, the chance that a visitor will follow a dead link to your site exists. If a visitor is trying to access a page on your site, the server will report (normally) a 404 error. The response is by default some unfriendly page with some spare information about the error which let most visitors stop visiting your site. But using the 404 error the right way, you the site owner can collect important information.

He talks about some of the data that could be collected - what page they were requesting, where they came from, access statistics and more. The tutorial shows you how to harvest some of this information and how to put Google's Search and Adsense tools on the page as well as Google Analytics for tracking.

On the Ibuildings techPortal today there's a new article from Lorna Mitchell looking at the phploc tool as a way to analyze your code and pick out a whole selection of statistics.

This has been a feature of PHPUnit for some time but has been released as a separate project in the phpunit pear channel. The nature of PHPUnit means that many of these statistics can be collected while the tests are running, which is why it was added to that tool in the first instance.

Stats gathered include the number of directories, files, interfaces, methods, functions and constants with more details for each (like visibility, actual lines of code contained in them and the cyclomatic complexity). The tool is very simple to use - just call it from the command like and give it a path to your codebase. It does the rest and spits out a text-based report.