Problem

I have rated a lot of movies on Rotten Tomatoes and I'd like to export them to a text format. I also know PHP. How can I do that?

Solution

In 2013 I wrote Rotten Tomatoes ratings exporter for the purpose of exporting the movies I had rated into a format I could read and also store.

To automate the process of acquiring the ratings, I wrote a small class which needs information available in the site's cookies once you are logged in. With this information in hand, it is then possible to fetch the ratings from the website and store them in any desired format, given that the data returned to you is a plain PHP array.

References

• https://github.com/tomzx/rotten-tomatoes-exporter

Problem

I have movie ratings that I would like to import into IMDb. I also happen to know PHP. How can I do that?

Solution

In 2013 I wrote IMDb ratings importer for the purpose of importing ratings I had created in another system (Rotten Tomatoes). I wanted to import my ratings into IMDb so that I could use their statistics reporting tools, which let you see your distribution of ratings and the distribution of the release year of the movies you've seen. A friend of mine also had his bot send a message to our discussion channel whenever one of us would update their ratings after watching a movie.

The library is pretty straightforward. It expects you to provide it with a string that uniquely identifies your cookie on the server side. With an array of all the titles and ratings that you have, you can submit those ratings and the library's importer will take care of calling IMDb by finding the closest movie title and assigning it the desired rating.

References

• https://github.com/tomzx/imdb-importer

Problem

I use semantic versioning 2.0.0 for my PHP libraries and I'd like to know when I generate breaking changes to my code. I would like to have a tool that tells me when that happens, as soon as possible so I can avoid creating backward-incompatible changes.

Solution

In 2015 I was working on a lot of PHP code and releasing various libraries as well as using a lot of libraries which were not always respecting the semantic versioning 2.0.0 rules. I understood that it was difficult to keep track of all the changes done to a codebase and that you needed a certain level of expertise to tell what kind of semantic versioning impact changes had. I knew that most of the semantic versioning rules however were rules that could be codified such that you could run a program that would look at a before and after snapshot of a piece of code and tell you how it changed. Those changes could then be categorized according to what they changed, and based on the semantics of semantic versioning, a semantic versioning change could be generated for the code change itself.

Thus PHP Semantic Versioning Checker was born. It analyzes a before and after snapshot of a directory of source code and generates a report of all the changes that occurred. It is then possible to review all the changes by their type (class, function, method, trait, interface) and their semantic impact (major, minor, patch, none). It also computes a suggested versioning change, which is the highest semantic impact found amongst the different types inspected.

I hope that this library and the concept of scanning source code for semantic versioning changes becomes more mainstream, such that every project runs this kind of tool as part of their CI pipeline.

References

• https://github.com/tomzx/php-semver-checker

Problem

I wrote some new code or edited code in my PHP application and I'd like to know if this change is covered by tests.

Solution

The approach I thought of to solve this problem was to write your change, run your tests (most likely using PHPUnit), then create a diff/patch of those changes and use this information to determine whether the lines that are part of the diff are covered. It should be relatively straightforward to automate the process of generating a patch from within a git repository as well as running PHPUnit within a project's directory (generating a clover.xml report). With this information in hand, it would be possible for a script to compute what is and isn't covered by tests in the changes that you are about to commit.

I wrote PHP Code Coverage Verifier which takes care of reading the PHPUnit output (a clover.xml file) and a generated patch file and produce a report of the lines that are and aren't covered.

An example of the script output is as follow:

php vendor/bin/php-code-coverage-verifier verify my-clover.xml my-diff.patch
Using clover-xml file: my-clover.xml
With diff file: my-diff.patch

Covered:
controller/admin/stocks.php line 15 - 21
controller/admin/stocks.php line 91 - 97
controller/search.php line 26 - 32
controller/search.php line 376 - 384
model/user.php line 34 - 41
model/user.php line 44 - 51

Not covered:
controller/account.php line 39 - 45
controller/admin/stocks.php line 27 - 33
controller/search.php line 36 - 42
controller/search.php line 187 - 193
model/user.php line 533 - 540

Ignored:
application/composer.json

Coverage: 40 covered (56.338%), 31 not covered (43.662%)

Reference

• https://github.com/tomzx/php-code-coverage-verifier