Monitoring TICK Stack Ubuntu

Installing the TICK Stack Tools to Collect Metrics

The TICK Stack is a great platform if you want to gain some visibility over your applications. However, looking into how to install it can be a little overwhelming. There are four tools that you need to install to use it:

  • Telegraf to collect the data
  • InfluxDB to store the data
  • Chronograf, the UI to view the data
  • Kapacitor to process the data in real time

All these tools are documented individually, with instructions on how to install them. But I wanted to have simple instructions to install all of them in Ubuntu and get started quickly.

Installing the Tools

First, add the InfluxData repository to your machine

curl -sL | sudo apt-key add -
source /etc/lsb-release
echo "deb${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Then install the applications

sudo apt-get update && sudo apt-get install influxdb telegraf chronograf kapacitor

To configure Telegraf, edit the file /etc/telegraf/telegraf.conf and uncomment the [[inputs.statsd]] section.

Inside the statsd section, uncomment the templates and add the templates you need. You can find more information on the format of the templates in the Telegraf documentation.

templates = [
 "cpu.* measurement*",

Now make sure all the needed service are started.

sudo service influxdb restart 
sudo service telegraf restart 
sudo service chronograf restart 
sudo service kapacitor restart

Configure the UI

Chronograf is installed, and listening on port 8888. I installed in in a PuPHPet VM, so mine is available at 

You can leave all the default values and click on Add connection.

Next, you will need to configure Kapacitor. Click on Configuration in the left toolbar.

Click on Add Kapacitor Connection in the Configuration page, leave all the Kapacitor settings to their defaults and click on Connect.


Test The Applications

Log data to the template you created earlier.

echo "blog.views.home.pageview:1|c" | nc -w 1 -u 8125

Check in the database for the data you inserted.

$ influx
Connected to http://localhost:8086 version 1.5.1
InfluxDB shell version: 1.5.1
> use telegraf
Using database telegraf
> select * from blog_views
name: blog_views
time host metric_type page pageview
---- ---- ----------- ---- --------
1522440310000000000 machine1 counter home 2
1522440320000000000 machine1 counter home 1

You should also be able to see the inserted data in Chronograf.

Click on Data Explorer in the left side menu. Choose telegraf.autogen DB, and explore your data.

Cronograf Data Explorer
Chronograf Data Explorer
Web Development

Asking For Help

I think one of my biggest weakness as a developer is that I rarely ask for help. Many times, I have spent hours trying to figure out a problem when all I needed to do was ask someone.

I started my career being the only developers of a small company. Back then, I had not heard about the importance of networking. So I had almost nobody I could turn too if I needed some help. I had no choice but to become very self-reliant. I learned pretty fast that Google was my best friend. Ok, back then it was AltaVista. I became very confident that I could find a solution to any problems I encounter. It was probably never the best solution, but I usually got what I needed done.

Today, I have a decent network. I am surrounded by very smart developers at work and online. If I have a problem, I can ask a coworker, ask on Twitter, on in IRC and chances are someone will know the answer and be willing to help me. I can also bounce ideas with those people and come out smarter out of it. Sadly, I almost never ask for help.

Maybe I got in the habit of finding solutions all by myself. But the real reason is that I am scared of what people will think if I ask questions. Will they start thinking that I am a bad developers for not already knowing that? How long would it take them to realize I am just a fraud if I ask them how to do my job all the time? I have all these brilliant developers I can reach out too, and I’m too dumb to ask them anything.

I really need to learn when it’s time to ask for help. If you are like me, you need to start asking too. Don’t be shy. Most developers are happy to help when they can. And if you don’t have a network, start now. Being part of the community is great.

Best Practices

Mocking PDO in PHPUnit

The subject of mocking a PDO object in PHPUnit has come around a few times lately. It cannot be done like normal classes because a PDO object cannot be serialized.

$pdo = $this->getMockBuilder('PDO')

This will work on another class, but with PDO you will get this error:

PDOException: You cannot serialize or unserialize PDO instances

The solution

My solution for this problem is to create a class that derive from PDO. This class has only an empty constructor. Then you can mock this class, making sure that you don’t disable the original constructor. This way the mocked object can be passed to the code to test even if this code does type hinting.

class PDOMock extends \PDO {
    public function __construct() {}

class PDOTest extends \PHPUnit_Framework_TestCase {
    public function setup() {
        $pdo = $this->getMockBuilder('PDOMock')
Events Training


In the next few months, I will be a 2 conferences.

True North PHP

True North PHP is a new conference that will be held in the Toronto area. It will be on November 2nd and 3rd. I’m very excited as I was chosen to speak. I will give an introduction to Continuous Integration. If you’re curious about CI, come see me.

They managed to get an amazing line up of speakers. And at $200, the tickets are really affordable.


Confoo will have its fourth edition from February 27 to March 1st of 2013. Confoo is always great and the next edition promise to be as good as the previous ones. I will not speak there, but I will attend it.

If you’re in the Montreal region, buy your ticket, you won’t regret it.

Best Practices PHP

Continuous Testing in PHP with Guard

A few months ago, I wrote about continuous testing. When I wrote that post, I was using watchr to run my tests. A few weeks ago, I started using Guard instead of watchr and I wouldn’t go back.

Reasons to Change

One of the problems I had with watchr, is that it did not see new files. Every time I added a test file, I had to switch window and restart watchr. Then I would add the class to test and have to do the same thing. It’s not a big deal, but I’m lazy. And the main reason to use a tool like this is to have the test runs automatically.

Another concerns, is that watchr is not maintained anymore. The latest commit on GitHub was done over a year ago. And the last time there where any real activity is 2 years ago. There is a couple pull requests waiting, but some of them have been there for a year.

And lastly, Guard comes built in with some functionality that required code in watchr, and others are part of additional Guards.


Like watchr, Guard watch your file system and trigger some actions when files are modified. It’s also build in Ruby. There are many plugins that will simplify frequent tasks. One of those is guard-phpunit that runs PHPUnit when PHP files are changed. Guard runs only the needed tests when you change a file. It will run all the tests only when you ask for it, or after a failing test finally succeed. It also has a very good notification system.

To install Guard, you need to have ruby already installed. On Ubuntu, you can install it like this

sudo apt-get install ruby1.9

Once you have Ruby installed, you just need to run

gem install guard guard-phpunit

to install Guard with the PHPUnit plugin. If you don’t use RVM to manage your Ruby versions, you will need to run gem install with sudo.

That’s all there is to it. You are now ready to use Guard.

The Guardfile

The Guardfile is where you tell Guard which files to watch, and what it should do when a file is modified. You can generate one with all the plugins installed by running

guard init

If you want to have a file only for one plugin, or add the code for another plugin, just run

guard init phpunit

You can also generate the Guardfile manually, it’s a simple Ruby file. My Guard file for PHPUnit looks like this:

guard 'phpunit', :cli => '--colors', :tests_path => 'tests', 
        :keep_failed => true, :all_after_pass => true do
  watch(%r{^src/(.+)\.php$}) { |m| "tests/#{m[1]}Test.php" }

The first line, tells guard to use the PHPUnit plugin. This plugin will execute PHPUnit and check if the tests pass or not. We give it a few options. First we tell guard to pass the colors argument to PHPUnit. keep_failed is to make sure that when a test case fails, guard will run it on every save until it passes. all_after_pass, tells Guard to run all the tests once a failing tests succeed. This way you are sure you didn’t break anything in the process of getting the test to pass.

This file has two calls to watch, the first one makes Guard watch the tests folder and run PHPUnit on any file modified in it.

The second one watches the src folder. When a file is modified in this folder, it makes Guard run the associated file in the tests folder. For this to work, I just have to keep the structure of my src and tests folders identical.

Running Guard

Running Guard is done by simply issuing the ‘guard’ command in your project folder. It will look for the Guard file in the current directory. If there are none, it will look in your home directory for a file called ‘.Guardfile’.

In addition to the ‘.Guardfile’, you can use a file called ‘.guard.rb’, also in your home directory. .Guardfile will be use if you don’t have a Guardfile in the current directory. .guard.rb is appended to your Guardfile. This is useful for configurations that you don’t want to share between developers on the same project. Notifications preferences are a good example of what can go in .guard.rb.

One interesting parameter to Guard is -c or –clear. If you run it with this parameter, Guard will clear the terminal before running the tests.

Running Guard
Running Guard


Guard has a comprehensive notification system. It uses Libnotify on Linux, Growl on Mac and Notifu on Windows. To use it on Linux, make sure you have libnotify-bin and the libnotify gem installed.

sudo apt-get install libnotify-bin
gem install libnotify

You can then add this line to your Guardfile

notification :libnotify

If you want to turn them off, change the notification value to :off.

notification :off

Other Plugins

There are a lot of plugins for Guard. Here’s a small list of the ones I found interesting:

Inline Guard

When there are no plugin to perform a task you need, you can use guard-shell. Another alternative is to create an inline guard. Just add a class that extends Guard to your Guardfile. In the class you need to at a minimum override the method run_on_change. Here’s what I did for running Behat.

module ::Guard
    class Behat < Guard
        def start 

        def run_all
            puts 'Run all Behat tests'
            puts `behat`

        def run_on_change(paths)
            paths.each do |file|
                puts `behat #{file}`

guard 'behat' do
    watch %r{^tests/integrationTests/.+\.feature$}

This runs Behat every time a .feature file is changed.

I'm working on a plugin for Behat. There is not much yet, it just runs Behat on file changes. It won't parse the results or display notifications yet. I still have a lot of work, but it can be useful as it is now. It's on my GitHub.

Give It a Try

Continuous testing has been a great addition to my toolbox. It took me some time to find the correct tools for me, but now, Guard is making my life easier. If you do Test Driven Development (TDD), you should try it.

If you have some better tools, or improvements I can make to the way I use Guard, please let me know in a comment.

Update 2013-11-15

The Guard::PHPUnit plugin has some issues. The main one is that it's calling a PHPUnit function that does not exist anymore. The name had a typo in it and it got fixed. There is a pull request to Guard::PHPUnit to fix it, but it's not maintained anymore.

Someone as forked the repository and create Guard::PHPUnit2. The fork fix the issue. And it will also provide a way to pass the path to PHPUnit. This will allow using it with Composer.

Make sure you use Guard::PHPUnit2 to avoid a lot of problems.


PHP Resources

A co-worker recently asked me how I stay current with new development in the PHP world. I started writing a document for him, then I though it might be a good idea to put this in a blog post. So here are a few of the resources I use. Most of them are about PHP, because that is what I was asked about, but I think it’s important to look other areas also. So I will throw in a few links that are not strictly about PHP.

I use Google Reader to subscribe to a lot of blogs, probably too many. I also use twitter to find out what’s happening. I follow people who are very active in the PHP, agile and software craftsmanship communities. When I see something interesting, I add it to Instapaper, so I can read it when I have time.


Aggregators are great, by following a few, you can quickly get a good view of the community.

The main one for PHP is without any doubt PHPDeveloper. This aggregator is maintained by Chris Cornutt. You can check the website or the Twitter feed, but don’t miss this one. Everyday, you will get links to 4 or 5 of the best articles published in the PHP world. You will also get weekly reminder of the best posts of the week and of what was popular a year ago.

Here’s a few other aggregator:


Those are some of the PHP blogs I follow:


Podcasts And Screencasts

User Groups

I attempt a few user groups here in Montreal. I go to PHP Québec every months and to JS-Montreal, Montreal.rb and OWASP Montreal every time I can. You probably have some user groups in you region. Check them out. They are great for learning and making contacts with other developers.


Conferences are more expensive, but they are really worth it. Here in Montreal, we have ConFoo that is amazing. There is also Agile Tour that is coming in November. This year, I will also be at the first edition of True North PHP in Toronto.

Conferences are a good way to be introduce to many technologies. You get back home with lots of new ideas. And a lot of things to research.

PHP Mentoring

PHP Mentoring is a new project that connects mentors with apprentices. I joined the program as soon as I heard about it and I’m very happy I did. I found two apprentices and a mentor in a few days. This is a great way to improve and learn a lot.

If you haven’t looked at it, I suggest you go read the guidelines and rules and put your name on the signup page on GitHub. It does not matter if you do it as a mentor, an apprentice or both. I’m sure it will help you a lot.

When your name is there, look for someone who matches what you are looking for in the names already there and contact him. I see a lot of names there, and not enough matches.

Those are a few of the resources I check to stay current. There are a lot more in my feed reader and in the list of people I follow on Twitter. But I think those are the most informative when it comes to PHP development.

If you think I missed some good ones, please leave a comment. I’m always happy to find more sources of great content.

Best Practices

Continuous Testing in PHP

Continuous testing is a way to automate the execution of your tests while you work. This makes the feedback loop very short. As soon as you save a file, the tests are run and you know right away if anything fails.


I discovered continuous testing over a year ago when I watched a video where Corey Haines performed a kata in front of a crowd. He was doing it in Ruby and using Autotest to run his test suite. I tough it was awesome that he immediately saw the result of his changes without having to do anything.

Back then I had used PHPsrc. It’s a great tool, but I didn’t like that I had to take my hand off the keyboard and click on a button to run my tests. So I was mainly running them from the command line.


When I saw Autotest, I was immediately sold and I looked for something similar in PHP. Sadly I didn’t found anything like it. So after a while I wrote something for myself. I called it AutoPHPUnit. It uses libnotify to watch the file system. Every time a file is changed, it runs PHPUnit. You can also specify a configuration file for PHPUnit.

It worked well for me, I really loved using it. But it was not very flexible.


Then I read the book Continuous Testing: with Ruby, Rails, and JavaScript (affiliate link) that I won at the Code Retreat in Quebec city.

In the book, the authors use watchr to monitor the file system and perform any actions when a file changes. Watchr can be used to monitor any kind of file, so it’s more flexible than my solution. And you tell it what to do with a Ruby block so it can react to changes any way you want.

To install it, you need to have Ruby already installed on your machine. Then you use RubyGems to install it. Simply run “gem install watchr” and you will have watchr on your machine. If you are not using RVM to manage your versions of Ruby, you might need to use sudo to install watchr.

You can then create a simple Ruby script. Calling the function watch() with a regexp for the files you want to watch and the block you want to execute when a file changes. Then, you run watchr passing it the script file as a parameter.

Here’s a simple script to run PHPUnit:

watch ('.*\.php$') {|phpFile| system("phpunit -c phpunit.xml")}

I watch every file that ends with ‘.php’. When watchr detects a change, it simply runs PHPUnit for me.

watchr running
watchr running


Using watchr like this is great if you have enough screen space to show a terminal beside your code. But if you can’t have a terminal on the screen at the same time as your editor, you can use notify-send on Ubuntu to get a pop up in the notification section.

watch ('.*\.php$') {|phpFile| run_php_unit(phpFile)} 

def run_php_unit(modified_file)
    if (system("phpunit -c phpunit.xml")) 
        system("notify-send 'All test passed'")
        system("notify-send 'Test failed'")

You can add any logic you want. In the Continuous Testing book they go further. You can have it display notifications only when the tests fails and when they pass again for the first time. They also count the numbers of successful runs and display notifications every 5 consecutive successful run.

watchr notification
watchr notification

Beyond PHP

The main advantage of watchr is that it is not limited to only testing Ruby or PHP. Since you are using a block of Ruby code, you can do almost anything. At work, we are starting a little Node.js project, and I plan on using it to run the Vows tests.

Here’s a few other things you can do with it

  • Compile CoffeeScript
  • Run PHP Code Sniffer
  • Run lint tests
  • Minify your JavaScript and CSS

Basically, anything you can automate can be ran every time a file of a certain type is changed. I’ve seen only one drawback to watchr, it does not see new files. So when you add files, you need to restart it if you want them to be monitored.

Update 2012-09-04

I posted a follow up about Continuous Testing. I now use Guard to run my tests automatically.


Clean Coder

Yesterday I finished reading The Clean Coder: A Code of Conduct for Professional Programmers (affiliate link) by Robert C. Martin. In this book, Uncle Bob expose his view of what it is to be a professional programmer. The author have been programming for 40 years and he have very strong opinion about the subject of professionalism in programming.

The Book

In the first chapter he defines professionalism in our career. A lot of it turns around taking responsibility for our actions. He also compare our profession to being a doctor by saying that we should Do no harm. We should strive not to harm the function and the structure of our programs. He then describes the means by which we should ensure that we don’t hurt our code. Those means are the subject of the rest of the book.

The following two chapters are about how we answer requests. The importance of saying no, and of delivering when we say yes. We should never accept to commit to something we can’t deliver. But when we commit to something, we need to make sure we deliver it. Uncle Bob publish a great story taken from the blog of John Blanco that is really worth reading. It’s a great example of how bad it can get when we fail to say no. John also has a great recipe for manipulating developers. Tell them the the app is simple, add features by faulting them for not seeing their necessity and push the deadline to get them to do more. Reading it made me realize that I have seen it in action many times. And I had fell for this trick myself.

He then follow about the actual act of coding. How we should prepare to code. The importance of being rested and free of worries. He takes a stand against “the zone” talks about how we should be more forgiving of interruptions. He also speaks about the importance of helping others and being helped by others.

The next chapter is about Test driven development. This is something I try to practice more and more. I already wrote a post about it.

He then move on practicing. He describes Code Kata and coding dojo. He also talks about how to get more experience by contributing to open source projects.

The next two chapters are about testing. He speaks about acceptance tests. How they should define the requirements and make the definition of done pretty clear. These tests should always be automated and should run pretty quickly. He then describes the testing strategies. The most important thing to remember, is that QA should not find anything. He list the different kinds of tests and their goals.

In chapter 9 and 10, the author speaks about time. How to manage it and how to estimate projects. He mentions meetings, how they can be important, but also useless. We should try to be in the important one, and use the Law of Two Feet when we end up in the others. He also mention The Pomodoro Technique and avoiding getting caught in blind alleys and messes. Then he mention a few techniques for estimating tasks.

Chapter 11 is about pressure. How to avoid it, and how to mitigate it. Developers are often under a lot of pressure. Some of it we cause to ourselves by not saying no when we should. Some of it is caused by the importance of our work for our employers. Learning how to handle this pressure is important.

The following two chapters are about working with others. In chapter 12, the author speaks about collaboration. How important it is for us to collaborate with other developers, but also with other peoples. Then chapter 13 is about teams and projects. He describes the importance of having a good team that works well together.

Chapter 12 is about mentoring, apprenticeship and craftsmanship. He describes how valuable mentoring can be. A mentor can help bring a junior developer up to speed, but it also can help the mentor get a better understanding of what he has to teach. The author then describes an apprenticeship model where developers would start as an apprentice before moving to being a journeyman and finally a master.

The books ends with an appendix on the tools the author uses. He mentions source control, testing tools, editors, issue tracking and continuous integration servers.

My Take On All Of This

The Clean Coder is a very good book. Uncle Bob have a very strong opinion on how software should be developed. I don’t agree with everything he says, but in general he makes good points.

One of the interesting things about the book is that it is full of stories taken from the career of the author. He show us how to become better developers by showing us some of his failures. Seeing how and why he failed can help us avoid some of these mistakes.

I wish I had this book earlier in my career, but I’m not sure I will have understand it’s importance. It his a great handbook on improving as developers. And it’s a great reminder of how far I still need to go if I want to consider myself a professional developer.

Best Practices PHP

Test Driven Development in PHP

Test driven development (TDD) is at the core of the Agile Methodology and Extreme Programming. This practice has been known for a while and a lot have been written on it. However, I still meet developers that don’t know what it is. I understand that many employers won’t let their employees write tests, but we should at least know about the best practices of our industry.

In this post I will describe TDD as I understand it. I will also talk about the tools that are available in PHP.

What Is TDD

In TDD, developers write a failing test before writing any production code. The expected behavior of the code to write is defined this way. It is then easy to know when we have reached this goal. This produce a very small feedback loop. It also push the developer to write code that is very loosely coupled to the rest of the system. This code is easier to change, and it can be reused outside without having to bring half of the current system.

One of the greatest advantage TDD comes with maintenance. You can modify your existing code without the fear of breaking anything else. Because the code is loosely coupled, the risk of side effects is practically non existent. If the behavior of the application change in any way, your tests should warn you. You should also always write a failing test before fixing a bug. This way if the bug gets reintroduce, you will know right away.

How To Practice TDD

Practicing TDD can be resumed with the following mantra: red/green/refactor. Red is a failing test. You write a test for the simpler thing you can achieve. Then you write the code to make that test pass and go to green. You should write as little code as possible to get the test passing. Commit any crime you need, the only important thing is to get back to green. Then in the refactor phase, you fix the code you wrote. Remove any duplication, make sure the code is readable, use descriptive names… Just make sure your tests are still passing while you refactor. And then, you go back and write another failing test.

Robert C. Martin (Uncle Bob) wrote The Three Rules Of TDD. It is a great read, but here are the rules:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You can see the very short feedback loop in those rules. There is also a strong emphasis on writing as little code as possible. Just write what you need and nothing more. This goes with the YAGNI (You ain’t gonna need it) approach.


PHP has two main tools for unit testing. Simple Test and PHPUnit. I always used PHPUnit for unit testing in PHP. I love the tool, it integrate with Eclipse and it can generate code coverage reports. Apparently Simple Test is pretty good also, but I have never tried it. You can pick any unit testing framework you like, just start writing test.

To write unit tests with PHPUnit, you simply create a file with a name ending by ‘Test.php’. If you want to test a class named KarateChop, you create the file ‘KarateChopTest.php’. In this file you create a class KarateChopTest that extends ‘PHPUnit_Framework_TestCase’.

You then create your testing methods inside this class. The testing methods must be public and their names must start with test. I just found out that you can use the @test annotation in the docblock instead of prefixing your method name with test. All your test will be run in isolation. An instance of the test class will be created for each test method. Just be careful with global data. Global variable and static properties can make you code very hard to test.

If your methods needs some code to prepare the test, you can create a setup() method. It will be call before every test. You can also add a teardown() method to do any clean up after the test.

Your test methods should be small. They should test for only one behavior, and every test should end with an assertion that verify that the system under test (SUT) behaved has expected. Don’t forget to write the test before the actual code. This way you can see the test fail first, and when it will pass, you will know that the system act as intended.

To verify the results of your test, PHPUnit has a wide range of assertions. They go from the simple assertTrue to more elaborates ones like assertEqualXMLStructure and assertGreaterThanOrEqual. I counted 36 assertions types in the documentation. It even have an assertThat method to write tests in the Behavior Driven Development style.

All your tests could simply use assertTrue to verify a condition, but the intent of your code is more obvious with the verbose assertions. Those 2 lines are the same:

$this->assertStringStartsWith($prefix, $string);
$this->assertTrue(0 === strpos($string, $prefix));

But the first one says what it is I’m testing.

To run your tests, all you need to do is run phpunit, passing it the file with the tests as a parameter. If you pass it a folder, PHPUnit will run the test in every files with a name ending by ‘Test.php’ in that folder and any sub folders.


Sometimes, you will need to have some code run before all the test cases. You might need to alter the require path, add an autoloader or set some environment variables. PHPUnit allow us to pass it a bootstrap file. This file will be run before your tests to prepare your testing environment.

phpunit --bootstrap Tests/testBootstrap.php .

Testing Databases

One of the common issue when doing TDD, or writing unit tests in general is how should we test code that interact with the database. The short answer to that, is don’t. Your database should be tested during your integration tests, not in unit tests. You should try to keep your data access layer isolated from the rest of the code. That will help you testing, but also make changing the way you store your data easier.

However, we work in the real world and we sometimes have to test code that access a database. To make it easier, you should not create the connection, but require it in the object constructor or as a parameter to the method that use it. If you can’t do this, consider creating a setter that allow your testing code to inject a different connection.

Make sure you use PDO connections and try to stick to standard SQL. This way in your tests, you can create a SQLite database and pass it to your tests. Make sure that you create your database in memory, not in a file. This way each test will have his own database and they will stay isolated. Creating a database like this can become very cumbersome if you use a lot of tables, or need to populate them with a lot of fake data.

If you need to connect to a real database to run your tests, you can pass your code a different configuration so at least it does not connect to your production server. You can also add an entry to your hosts file so when you try to connect to production, you end up in the test database. This can be dangerous though, someone might end up running your tests without the entry in the hosts file and alter your production database.

Connecting to a real database cause problems with the isolation of the tests. Changes made by a test can alter the result of another test. Testing against a database can also be very slow. So you should do this only if you have no other choices.


I already wrote about PHPsrc in a previous post. This tool will allow you to run your tests from inside Eclipse.

PHPsrc PHPUnit Configuration
PHPsrc PHPUnit Configuration

The PHPUnit integration will allow you to easily run the tests. It can also jump between the tests and the class being tested. You can give it a bootstrap file in the configuration. Either in the global settings, or by project. It will underline failing tests as errors, and it can also show code that is not covered by your tests.

Where To Start

Beginning TDD is not an easy task. At first it will slow you down. You might appear to lose some productivity, but you should catch up pretty fast. Especially when you will maintain your code. You should then be able to make changes while being confident that you didn’t break anything.

If you want to be good at anything, you need to practice. There are many resources available to practice TDD. You can perform some Code Kata, attempt a Code Retreat, find a Coding Dojo or try CyberDojo. All these are excellent, just go and practice.

If you need any more information about TDD, I would recommend reading Test Driven Development: By Example (affiliate link) by Kent Beck. It starts with an in-depth explanation of TDD and finishes by implementing an xUnit framework in TDD.

Best Practices Events Training

Code Retreat Quebec

Last Saturday I had the privilege of attempting a code retreat in Quebec City. I have been hoping for this for a while, so I registered as soon as I found out about it. When I learned that Corey Haines and J. B. Rainsberger where going to be there I was really thrilled.

The Setup

The event took place at the Germain-Dominion Hotel. It is located in the old port district of Quebec City, close to the fortifications.

The retreat started at 8 AM with a breakfast and finished at 5 PM after 6 sessions of coding. With had 2 coffee breaks and a nice diner. The room was nice, with plenty of plugs for the laptop and a good WiFi connection. The organizers did a great job setting this up. Everything was ready for a full day of learning.

How The Day Went

After the breakfast, the actual retreat started by an introduction from Corey. He describes the goals of the retreat, how it got started and the problem we where going to work on. If you are interested in his introduction, you can look at the introduction he gave in Cleveland in January.

Cleveland Code Retreat Introduction from Corey Haines on Vimeo.

After that, Corey explained that we where going to focus on the The Four Elements of Simple Design. They are in order of importance:

  • Passes its tests
  • Minimizes duplication
  • Maximizes clarity
  • Has fewer elements

Then we started the first session. Each sessions lasted 45 minutes. During this time we had to do Pair programming to work on the problem. Every time we tried to produce the best code we could. And at the end of the session we had to delete the code. Then Corey did a brief recap of the session and gave some tips to help us move forward. Then we had to find another partner for the next session.

At the end of the day, we took pictures, then we formed a circle and everyone had to answer 3 questions. What we learned, what surprised us the most and what we will change at work.

My Impressions

The first thing I notice is that there where people programming in many different languages. We where a few PHP developers, but not all of us had a testing environment ready. I was happy to show some people how to do TDD in PHP with PHPUnit.

During the day, I paired with six different developers. We covered Java, C#, PHP and Python. I got to work with good developers. The pairing is probably the greatest thing about the retreat. During each session we got to exchange ideas with someone else. Every one brought a different way to attack the problem. This is a great chance to try to code differently. Especially in a setup where we can take the time to do it correctly, with no pressure to deliver. Pairing is also a great way to transfer knowledge. While working in pair, you can learn things such as language features, better design, IDE features and keyboard shortcuts. All this just by looking at the other developer.

Practicing Test-driven development during an entire day reminded me of how much I love it. Even in an event like this one, not every one I paired with was doing TDD. Some started by writing some code before adding a test to verify it. But when I was doing TDD, it really felt like the correct thing to do. I know I still need a lot of practice, but when I did TDD, programming was just more fun.

What I Got Out Of It

I think the greatest lesson I got from the code retreat is a new perspective on programming. Now I will try to look at my projects for another angle. Corey and J. B. made me realize that even if we are all against the waterfall approach, we still tend to over-think our design before we start coding. On the first 3 sessions, I started with a Cell class. It seemed like it was a good starting point because it will be needed for the game. But it was a dead end.

Corey told us that when we are ready to start coding something, we should ask why? Why are we coding this? Then take the answer and ask why again. After a few time we will reach a point where we cannot ask it anymore, this is where we should start.

With the Cell class example, I was starting there because I needed to know if a cell was alive or not. I needed to know this because I needed to check if a cell needed to be killed or not. I needed this because… In the end, what I needed is a board to play the game of life. Starting with the board seemed counter intuitive to me, but when I tried it everything fell into place.

I also got to see some Python. This is a language I barely know. Pairing with a Python developer was really fun. I think I could really like this language. I especially liked the list comprehension. This is something I really wish we had in PHP.

What Now?

The code retreat was fun, I got to experiment with practices that are not accepted where I work. It is now up to me to try and change that. I already used TDD on some project. But I really need to get back to doing it as much as I can. If it does not slow me down, and I end up producing better code, nobody can complain about it. It would also be great if I could get the other members of the team to try it. I gave a little presentation about it at work over a year ago. Sadly as far as I know, no one else tried it.

Pair programming is harder to sell. I still think it’s an amazing way to transfer knowledge. It can help bring up to speed a new developer. Pairing a junior developer with someone with more experience can help both of them. The junior will get an access to the knowledge and techniques of an experienced developers. And the experienced one should consolidate is knowledge by explaining it. And he may also learn something from the other developer.

I also have to thanks the organizers, the sponsors and the facilitator. They made this amazing event possible. For only 30$, I got to spend a day coding with better developers than me. I hope it made me a better programmer, and I am looking forward to the next event.


Karl Metivier has posted the videos of the introduction that Corey Haines did at the Quebec code retreat.