Category: PHP

Virtual disk design kata

In my current job (ulabox) we do every Thursday a internal training session, usually prepared by one of our department members. Some months ago I prepared a code kata on design patterns, with 5 steps with instructions. The idea was to push the team to debate about different approaches to a common problem, and show them some classical design patterns, as a way to polish our weapons. The result was good, but the discussion only really happened at the end, when I showed them those patterns.

Ninja weaponsSome weeks later I heard about a code conference in Barcelona, organized by the Barcelona Software Craftsmanship group, so I took the chance to polish my kata and ask them to do in the event. It was rejected to the main event.

Later I heard about Monday’s katas: this group organizes every Monday a code kata with up to 20 developers. I offered my kata and our office to do it, and on December 12th we did it! All participants agree: the kata is smooth and induces to think about the subjects it later shows.

I published my kata on github. Have fun!


Do you test your tests?

Weird shapesThe first time I read about serious testing was in The Pragmatic Programmer. The book explains the usual (boring) benefits of testing, but a twisted detail rolled my eyes up: also test your tests. Testing is a net that helps you to change the code without breaking the logic, and as a real life net, you should verify it works as expected. Tests should be in a tight relation with the code.

When is a test good? Trying to find the differences between a good test and a bad one is not obvious, however. Looking for lacks or anti-patterns in our tests is a good option to improve them.

Thanks to PHPUnit and Xdebug, the PHP community started to care about testing years ago. Since then, the easiest way to show the quality of a test suite is the code coverage, that is, the percentage of the code the test stresses. That worked until programmers started to focus on a 100% coverage, creating artificial tests that doesn’t stress the logic correctly, but instead get a fake 100% line coverage. If a line is executed once, even if the subject was a different test unit that uses that class, the line “is tested”.

Are you really testing each class? Following the logic? Even if you use proper unit tests, you may be missing things.

Let’s start with a stupid example, a function that does an “AND”, and a tests that gets a 100% coverage:

class MyOperator
{
    public function doAnd($param1, $param2)
    {
        if ($param1) {
            if ($param2) {
                return true;
            }
        }
        return false;
    }
}

class MyOperatorTest extends \PHPUnit_Framework_TestCase
{
    public function testDoAnd()
    {
        $operator = new MyOperator();
        $this->assertEquals(true,  $operator->doAnd(true, true));
        $this->assertEquals(false, $operator->doAnd(true, false));
    }
}

The test is only stressing 2 cases! Actually an “AND” has 4 possible cases, so the 2 missing cases (false-true, false-false) were totally ignored, despite you get a 100% line coverage.

This was a basic example to show the difference between line coverage and path coverage (in this case, 4 possible paths). The good news is that Derick Rethans is working on it. I wonder how many programmers will get surprised while seeing their code’s path coverage is low.

Another way to test your tests is to change the source code and see if the test fails (it should!) or not. This is called Mutation Testing, and helps to detect when a test is not working perfectly. For instance:

    public function biggerThan5($number)
    {
        if ($number > 5) {
            return true;
        }
        return false;
    }
/* ... */
    public function testBiggerThan5()
    {
        $operator = new MyOperator();
        $this->assertEquals(true, $operator->biggerThan5(8));
        $this->assertEquals(false, $operator->biggerThan5(3));
    }

This test looks complete, but there is no test for the bound case, biggerThat5(5). This test is not really accurate.

In the PHP ecosystem there are 2 only available Mutation Testing tools: Humbug and Mutatesting. The second one, despite the author is also the creator of the excellent PHP-metrics, seems abandoned.

So the only real option is Humbug, developed by the author of Mockery. Unluckily it only works with PHPUnit for the moment. It basically finds places where the code can be easily changed, like a true for a false, or a number N for N+1, and runs the tests to see if that mutation is killed (that is, the test fails). For instance, in the previous example it changes 5 to 6, and the tests still work, so the mutation was not killed.

I just hope these tools become more popular, in order to improve the quality of our industry. And let’s hope soon Humbug will work in PHPspec too, as many companies are moving from PHPUnit to Behat-PHPspec.

The code of this post can be find at its github repo.


The most required PHP packages

composerComposer is the most used package dependency manager in PHP ecosystem since a few years. It manages complex dependecies with an easy syntax, and you can easily search among all available packages in packagist.org, where you can publish your own too.

It was interesting to find a list of the most required packages. Some of them are part of a framework, while others are lonely gems. As a person that values professionalism, it should be a must to have some experience, or at least know, the most popular packages. Here I’m having a look at some of them.

phpunitsThe absolute #1 is PHPUnit. If you are programming in PHP and have never used it, go and get a position as consultant, please. The PHP unit testing framework has been a popular choice since years ago (I’ve even posted about it in 2008). A must you should know.

The list contains other testing related packages too. #4 Mockery is an object mocking package widely used. In my personal case, I use Prophecy for mocking, which comes with #21 phpspec, a test framework that can complement or substitute PHPUnit. In the list also appears #44 behat, a tool for making scenario-oriented BDD that is rising popularity.

symfonyRegarding complete frameworks, the list includes lots of Symfony framework packages. #3 symfony/framework-bundle, #5 symfony/symfony, #8 symfony/console, #10 symfony/yaml, etc. Some of them are core to symfony framework, while others are so independent that are widely used, even without using this framework. A clear example of that is yaml package, which (obviously) processes yaml files.

Of course not only Symfony appears in the list, but also other popular frameworks like: Laravel (#2 illuminate/support, #47 laravel/framework), Zend (#13 zendframework/zendframework), Yii (#17 yiisoft/yii2) and Silex (#22 silex/silex).

doctrineApart from complete frameworks, the list comes with some other must-know packages. The DB-related Doctrine is the first to appear (#6 doctrine/orm, #31 doctrine/common, #38 doctrine/dbal). There are some code-quality related packages, like #7 PHP Coveralls, #11 PHP_CodeSniffer and #33 PHP Mess Detector. Finally some usual suspects, like #15 Guzzle (HTTP client), #19 Monolog (the standard way of logging, already included everywhere).

Finally, some packages in the list were a surprise to me, as I had no idea about them. For instance, #9 composer/installers (an multi-framework installer), #16 silverstripe/framework (a CMS) or #29 nette (another framework).

leagueLogoDefinitively it’s a great collection of packages, and if you combine them with the ones from The League of Extraordinary Packages, you will get a great stuff to learn from: 1st, know about them; 2nd, try to use them; and 3rd, read their source code.


How I looked for a new tech job

Sagrada Familia at nightBack in Barcelona after 3 years working remotely, I decided to look for a new in-office job. But following an uncommon way to search for a job.

First I had a look on jobs’ websites, but only to get an idea of what technologies are popular in Barcelona. Symfony was the most remarkable one. But I didn’t apply to any of the job offers I saw there.

I don’t want to work in a company just because they opened a job offer. I want to work in a company with great developers to learn from, and a product that passionates me. Actually I discovered that sometimes good companies need more developers but have no time to publish openings.

So I looked for a list of local companies. Regarding Barcelona, I found http://internetmadeinbcn.org/ (¹). And started to make a list with the interesting ones.

I also started to join programming events like conferences and talks, meeting people there. The idea was to find companies which technical level is a bit better than my skills(²). If you have the chance to join one of them, you’ll improve greatly.

Pretty Hot PeopleSend them your CV with a well prepared cover letter (email). Some of them will contact you back. And the real fun begins: TECH interviews! Usually the process starts with a tech test, where you have to program something in a short time (between 1 to 4 hours). By the way, if the company does not ask you to do a test, run away (read the reasons in Joel’s test); once I joined a company that didn’t ask me so, and 3 weeks later I quited because their code was not a good one to learn from.

True fact: you will do your first interview horribly.

However, you will learn a lot while having interviews and tech tests. Specially if you ask for FEEDBACK! From my experience, only half of them will send you some feedback (following Sergey Brin’s style, “make the candidate learn something”). Feedback is pure gold. It’s the best way to learn from other developers working in the industry.

In my case, while having interviews I learned some new code design ideas. Moreover I ended up reading about DDD and BDD. For instance, in the first interview (3 months ago) they asked me about the meaning of BDD, and I had no idea; but in the last tech test, totally based on behat, I was able to code comfortably.

I can only say thank you to the few companies that gave me valuable feedback, even if they didn’t hire me. Now I’m better thanks to them. Somehow they helped me to sharp my skills!

Summing up, the “always learn” mantra should be applied to the process of looking for a new job too.

AND I GOT A NEW JOB, yeah!

Notes:
(¹) For other cities in Europe, you may want to have a look at tyba.com.
(²) Actually this is a borrowed idea from my Korean classes in Seoul. The teacher always speaks using some more words and expressions that the students should know, so the students keep fighting all the time trying to get the level. However, students can get exhausted with that drowning feeling.


VIM plugins for web development

Recently I bought a new laptop, and while configuring my tools I noticed I haven’t cared about VIM plugins for years. It was the perfect time to have a look at the most interesting plugins.

Firstly I installed Pathogen to manage VIM plugins. It allows you to install other VIM plugins in separate directories. This way you avoid the mess the .vim directory can become.

vim plugins
Regarding general plugins, I installed NERDtree which is a directory tree explorer, ideal to keep a general view of your project. Also installed Airline, that shows an improved status bar with lots of information about the current file. However I couldn’t see it at first and I had to add the following line in my ~/.vimrc file.
set laststatus=2

If we speak about writing code, the most useful plugin you can install is SuperTab, which improves auto-completion with the tab key. This one works really well in pair with Ultisnips, that (as it name suggests) allows you to save snips of code and recall them later. I also added to my list the transparent Skeletons plugin. If you create a new file, this plugin gives you a template to start with, depending on the type of file you created.

Time to have a look at web development. In order to work with HTML, I installed matchit (a classic) but also HTML5, which adds omnicomplete funtion, indent and syntax for HTML 5 and SVG. As sometimes I use less to write improved CSS, I added Less, a single file with syntax.

The PHP programming section is based in the PIV (PHP integration for VIM), which includes various plugins. Actually I disabled some of them, just to meet my needs. Finally I added Syntastic: every time you save a PHP file, it automatically checks it with PHP’s lint (finds grammar errors), PHP Code Sniffer (alerts style errors) and PHP Mess Detector (suggests improvements), showing the results inline.

Am I missing any other basic plugin? I guess not, as with these tools I feel really backed to develop any project.

Update: I forgot to list xDebug (an interface for PHP’s xDebug).


Adminer, a compact database manager

tl;dr If you use phpMyAdmin, stop right now and give a try to Adminer.

If you have several customers with different hostings, you have experienced problems accessing to their MySQL databases for sure. The situation comes like this: you get a new support ticket and ask for hosting access, but usually you just get FTP access. So now you have to ask again about the phpMyAdmin URL. Or you get access to their hosting panel, but there is just a horrible DB manager.

What can you do? Trying to deploy phpMyAdmin yourself in a customer’s hosting is a nightmare, and can take several minutes. That makes no sense, specially if you just need to check a tiny detail.

adminerAdminer is the solution, as it is just one file. That means uploading it is just a couple of seconds. In a moment you are operating with the database. Magic.

I don’t really know how I discovered about Adminer, but as soon as I started using it, it became an everyday tool. Actually I don’t remember when was the last time I used phpMyAdmin. Adminer as a single file is perfect, but moreover it comes with a lot of features that surprass phpMyAdmin. And it has an active development, so each new version comes with new features, like more databases (PostgreSQL, SQLite, MS SQL, Oracle, SimpleDB, Elasticsearch and MongoDB).

Finally there is a cut-down version, Adminer Editor, that only allows simple CRUD operations. That’s perfect if you need to quickly provide your customer a way to edit the content while you develop a proper back-office.


Links about quality website development

Just for reference, here I’m writing down some interesting links I’ve recently seen about quality while developing and maintaining websites.

That’s enough to keep me busy for months. But these days I’m also trying ideas, using CSS3 and HTML5 features, so I’m using a lot what it could be the best website with compatibility features.


Telecommuting: when good forms are forced

Pouchong TeaCurrently I’m working for a company, at home. It’s a small company: my boss is located in Mexico, I’m (project leader) here in Spain, and there are 3 developers in India. We just use Skype, Google Docs and email, and we have no big problems, just the ones related to the time zones.

“When you work remotely you work less”, they say. Actually this is the usual excuse for bosses to avoid telecommuting, because they feel they can control you less. But this idea is totally wrong!

Let me explain an interesting effect. Imagine a man working in a office with fixed time (like 9am to 5pm); when he sees the clock marking 5pm he stops working and runs home (except just in case of a final deadline for a project). That is, he doesn’t really take care about finishing the job. Perhaps he has not done a lot of it, and instead he spent a couple of hours with minesweeper! Meanwhile, I don’t have a really daily schedule: but I usually do something like 9am to 6pm, with some stops. The thing is that when I see 6pm in the clock, I do NOT stop, just think “is the task (scheduled for today) done?”. Usually it’s not done, so I work a couple of hours more. Of course it depends on each person, but usually remote working make you more implicated with the job.

On the other hand, the company is forced to have a really good system to schedule tasks. Other methods to control the work that everyone is doing are welcomed as well. Things like an updated calendar for tasks, good version control system and code reviews, ways to verify the quality of software, job reports, etc. The company has to firmly use methods of control in order to survive. But this is a good thing: the work is better organized! In my case, we usually have a meeting on Friday (evening, morning) to set the tasks for each single day of the next 2 weeks, and review the tasks done during the current week.

So, the real benefits of telecommuting, from the company’s perspective: no need to rent an office (and no need to pay its bills), better organization of the work, and happier employees. Sounds good, specially nowadays with a economic crisis around. The only real problem is the communication with the team, but with video-conferences you can reach a just enough level of interaction. However, this doesn’t work for all kind of people, but you can train them (even remotely!) to work with the discipline needed to telecommute effectively.


Software metrics (PHP focused) part 2

In part 1 I spoke about lines of code and average of lines per day. Two indexes that are quite naive. Let’s see some better metrics, most of them object oriented programming focused.

Third stop: Tests and code coverage
If you have unit tests you can easily control that nothing vital is broken in each contribution. A unit test stress a class, so if there is some change in it, you can verify that the expected behavior remains the same. Moreover you can get an analysis of which lines of the code are actually executed in a test suite: that is, the code coverage of the test. You will see high values in well tested classes and low values in classes that need more tests.

Tools? Of course, PHPUnit, with the help of xdebug to get the code coverage.

Four stop: Cyclomatic complexity
Cyclomatic complexity is just the amount of different paths the execution can go throughout. For example, in our main project we have a total of 3048 paths. This value can be interesting to detect places in code that have become too complex and maybe need some cleanup.

Five stop: Pure OO software metrics
There are some interesting software metrics for object oriented code organized in packages, used basically to value which packages (groups of classes) are of better quality than others. Values that show the relation among classes, dependences, the resilience to change, etc.

Last stop: Ratios
Combining some of the previous values you can get interesting ratios. For example:
– Cyclomatic complexity per lines of code: 0.2, a very good value.
– Lines of code per method (class function): 22.02, a normal value that we have to lower.
– Method per classes: 8.25, a good value.
– Average number of extended classes: 0.4, a good value.
– etc…

Tools? The excellent pdepend is used here. Have a look at the end of its example page to see the amount of data (and funny but interesting diagrams) you can get.

Finally, all those values and tests are compiled each single time a programmer sends a commit to our code repository, and I get a mail with all the details, including the lines added, the author’s name, and all the values that change. So with a quick look I can assure that the contribution is ok, or there is some code to improve. I wonder how many companies (which develop in PHP) use something like this. I bet less than 100 in the world!


Software metrics (PHP focused) part 1

Managing a software project with various programmers and around 10 contributions per day is a complex thing.
How can we measure the quality of every single contribution?
How can control the work of the programmers?

First stop: Lines of code

The easiest thing to measure in a project is the source lines of code it has. For example, the main project we are developing at work has ~30k lines (k=1000). That is, 24k of pure code and 7k of comments (and I’m counting only pure PHP OO code, without HTML, CSS or javascript).

Is this that simple to count? No, it’s not. The main problem is that programming is brain work, where creativity, skills to solve problems, and smartness are put in play. It’s like writing a novel: can you say that one novel is better than other just counting the pages it has? Can you say a Boeing 717 is worse than a 747 because it weights less? As the Wikipedia’s article says, only this metric can be useful when comparing 2 projects with different order of magnitude. However, the ratio comments per lines of code (in my case 1 comment every 4 lines) usually is a good index of quality.

Second stop: Average lines per day

Calculating the average lines of code per day can be tricky as well. At my job, a senior developer usually does ~50 lines per day, but a junior programmer does ~130 lines. Is that much? Well, having a look at some metrics about a similar project, phpMyAdmin, in Ohloh (a website with metrics for open source soft), and doing some maths, it’s suggestion is just 17 lines per day! On the other hand, if you google for “lines of code per day” you will get really wide values, from tops of 1k (using code generators: tricking) to normal less-than-100 values. Moreover, the deviation from this average value is actually huge: one day I can do 2 lines, other day I can do 200.

Senior does 50 lines, junior 130… is the senior one a slacker? Of course is not… usually the code from the senior one is better: less prone to errors, more adaptable, more concrete function’s names, more elegant, and does more things in less lines. The more the better? Actually the less code needed to solve a problem, the better. About this topic, I recommend reading the article : Code is your enemy!.

Tools? We use phploc for counting lines of code, and phpcpd for detecting cases of duplicated code. Both tools are developed by Sebastian Bergmann, the author of PHPUnit (the most popular testing framework for PHP).

Next, in part 2 of this post, I’ll be speaking about other metrics, like code coverage, cyclomatic complexity and some interesting ratios based on software package metrics.