pds/skeleton is now stable

PHP Package Development Standard, aka pds/skeleton, is now stable.  I’ve linked to it before and I think it’s a great idea and I’m glad I’m not alone:

Roughly 78,000 packages already comply with the pds/skeleton standard, although they may not know it. To formally show that your package has adopted the standard, “require-dev” it via Composer, or display a badge on your README.

I’d gladly follow this standard for my own work too, except that I mostly work with WordPress and CakePHP these days, both of which do things differently from the standard and from each other.

WordPress kind of assumes that the whole project is public, so you don’t really get public/ folder.  It also organizes the code into wp-includes/, wp-admin/ and wp-content/ folders, instead of the src/ suggested by PDS.  And, in terms of configuration, everything goes into wp-config.php file instead of something in the config/ folder.

CakePHP is much closer to PDS in terms of organization of files.  The only difference that I can spot is the use of webroot/ folder instead of the suggested public/.

I’d really love to see larger libraries and frameworks adhere to the PDS, but until that happens, I’ll keep an eye on things.

P.S.: The standards comic strip is of course from xkcd.

PHP assertions

When I hear the word “assertion”, the first thing that comes to my mind is PHPUnit assertions.  Sure, I write assertions in my unit tests.  But is that the only application?  Today I decided to figure it out, or, at least, learn more about the subject.

It turns out that PHP has assert() and assert_options() functions.  And those were there since the ancient times of PHP 4.  Sounds cool, but how useful are these?  Well, not that much:

Assertions should be used as a debugging feature only. You may use them for sanity-checks that test for conditions that should always be TRUE and that indicate some programming errors if not or to check for the presence of certain features like extension functions or certain system limits and features.

Assertions should not be used for normal runtime operations like input parameter checks. As a rule of thumb your code should always be able to work correctly if assertion checking is not activated.

This StackOverflow discussion expands a bit on the subject and concludes that assertions are just a developer tool used for troubleshooting and such. Bummer!

But I’m not that easily stopped.  Next stop – search for tools and libraries on GitHub and Packagist.  There’s more luck here!  A whole lot of different libraries exist that help with asserting facts and matching values to patterns.  I’ve checked a few of them and here’s the Top 3 List that I’m considering for use in my code:

  • beberlei/assert – simple to use library, with a respectable number of implemented assertions.  It supports chained methods, lazy assertions, and is easy to extend.  (See this blog post, announcing version 2 a few years back.) Also, the fact that almost 300 projects depend on it, makes it an attractive choice.
  • nilportugues/php-assert – also an easy to use library, which offers even more assertions, grouped into a number of categories (generic, string, integer, float, array, date and time, object, and file upload).  It’s not anywhere near as popular as the previous option, but that is probably just a question of time.
  • peridot-php/leo – a much more advanced assertion and matching library than the previous two options.  In fact, so much more advanced, that it has a dedicated documentation website.  This is understandable, as this library is a part of the Peridot BDD testing framework.  It is easy to extend too, but I’m not sure yet that I need that level of complexity in my projects.

I found a few more alternatives, but they looked like side projects or small toolboxes for specific needs.  None of those impressed me enough to be linked here.

It’s too late at night to make a decision right now on which project I like the most.  But I will definitely play more with the ones above.  If you have any experience with those or with any other assertion/matching library, I’m interested to hear.

 

Use vimdiff as git mergetool

Ruslan Osipov has a very handy tutorial on how to setup Vim text editor as git merge tool, for resolving git conflicts.

Basically, run the following commands to tell git to use Vim as a merge tool (don’t forget the –global flag if you want it for all your projects, not just the current one):

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

With that, running “git mergetool” after a conflict was reported, will result in something like this:

The three way split window will show local version (–ours) on the left, the remote version (–theirs) on the right, and the base version with the conflict in the middle.  You can then get changes from one window into another using the following Vim diffget commands:

:diffg RE  " get from REMOTE
:diffg BA  " get from BASE
:diffg LO  " get from LOCAL

Awesomeness!

Check a few of Ruslan’s other vim-related articles.

The Most Mentioned Books On StackOverflow

Slashdot links to “The Most Mentioned Books On StackOverflow“.

How we did it:

  • We got database dump of all user-contributed content on the Stack Exchange network (can be downloaded here)
  • Extracted questions and answers made on stackoverflow
  • Found all amazon.com links and counted it
  • Created tag-based search for your convenience
  • Brought it to you

I’ve previously linked to a similar selection of “Top 29 books on Amazon from Hacker News comments“.