In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

Here’s a totally-contrived example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

    <?php
    public function testThatExceptionIsThrown()
    {
        // Use a helper to give us a ready-to-go parser
        $parseHelper = $this->getHelper('parseHelper');

        /**
         * If we pass a string as the first parameter to parseGrumpyRambling
         * instead of an array, we should get an exception generated because
         * we are using a type hint
         */
        try {
            $weirdCanadianWords = '';
            $phrase = "No doot aboot it, we're gonna win at hockey!";
            $parsedText = $parseHelper->parseGrumpyRambling(
                $weirdCanadianWords,
                $phrase
            );
            $this->fail();
        } catch (Exception $e) {
            $this->assertContains(
                'must be of the type array, string given',
                $e->getMessage()
            );
        }
    }

Okay, so why does this test offend me so much?

First, I am of the opinion that writing a test to check to make sure you are enforcing type hinting for your class method parameters is probably not a good use of your time. I mean, what potential problem are you catching?

Consider the following:

• you likely have access to info about what type of value each parameter is expected to be
• you are probably much better off filtering for parameter type before you even call that method

I can say with confidence that a test like this is returning very little value for the effort.

Second, putting any logic inside your unit tests is a great way to end up with unexpected results. Need an “if” statement? Write two tests for that condition. Need a switch / case? Again, one test per case is a much better way to logically divide things up.

The worst thing about using try / catch is that PHPUnit gives you two built-in methods to not ever have to use it. I’ve had people say to me “but Chris, if you use try / catch you get much better control over determining where in the process to test that the exception was thrown.” I don’t buy it, and I will try and explain why.

If you are using docblocks on your tests (which you should) it is super easy to indicate what exception you are expecting to be thrown.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

    <?php
    /**
     * @expectedException Exception
     * @expectedExceptionMessage must be of the type array 
     */
    public function testThatExceptionIsThrown()
    {
        // Use a helper to give us a ready-to-go parser
        $parseHelper = $this->getHelper('parseHelper');

        /**
         * If we pass a string as the first parameter to parseGrumpyRambling
         * instead of an array, we should get an exception generated because
         * we are using a type hint
         */
        $weirdCanadianWords = '';
        $phrase = "No doot aboot it, we're gonna win at hockey!";
        $parsedText = $parseHelper->parseGrumpyRambling(
            $weirdCanadianWords,
            $phrase
        );
    }

Now we have a much cleaner-looking test with no conditional logic inside it.

You can also choose to use a built in PHPUnit method to set what exception you are expecting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

    <?php
    public function testThatExceptionIsThrown()
    {
        $this->setExpectedException(
            'Exception',
            'must be of the type array'
        );

        // Use a helper to give us a ready-to-go parser
        $parseHelper = $this->getHelper('parseHelper');

        /**
         * If we pass a string as the first parameter to parseGrumpyRambling
         * instead of an array, we should get an exception generated because
         * we are using a type hint
         */
        $weirdCanadianWords = '';
        $phrase = "No doot aboot it, we're gonna win at hockey!";
        $parsedText = $parseHelper->parseGrumpyRambling(
            $weirdCanadianWords,
            $phrase
        );
    }

Again, a much cleaner-looking test with no conditional logic in sight.

On Twitter Brian Fenton shared a blog post he wrote back in 2011 that disagrees with me. In it he very briefly talks about why you should use try / catch in your tests, but I feel like he is contradicting himself when he talks about why.

Basically, Brian is concerned about how @expectedException and setExpectedException() can be triggered by other errors in your tests (including other exceptions being unexpectedly triggered. He feels that by using try / catch you have much better control over when and where you wish to trigger an exception.

To quote Brain’s post:

“The basic idea here is that the most specific test is best, because you have the least likelihood of a false negative or a test error slipping through the cracks.”

If you are making sure that every test is the most specific test that you can write, then you NEVER have to worry about whether or not some other code under test is throwing an exception or other error that is messing up the current test.

Using try-catch because you want to not miss errors that might occur before you deliberately throw an exception is a sign that you are doing too much in that test.

A test failure is a test failure, no matter what caused it. The harder you work to make sure that a test is actually testing the most specific thing possible, the less likely you have to worry about the things that Brian feels require him to use try / catch.

This is the same reason I don’t like seeing tests like this:

• do Task A
• do an assertion on the results of Task A
• do Task B
• do an assertion on the results of Task B

Those are really two separate tests, so split them up. In fact, you could write two tests that look like this:

• do Task A

• do an assertion on results of Task A

• do Task A

• do Task B
• do an assertion on the results of Task B

That second test doesn’t need to re-assert that Task A did it’s job because Task A was already covered in the previous test.

Test smells, testing anti-patterns, whatever you want to call them, do exist and many programmers are often unaware of the consequences of those decisions are.

Keep your tests small, keep them very specific, and don’t use conditional logic in your tests. I have yet to see a specific example where the use of conditional logic did anything except reduce the amount of lines of code a grumpy developer didn’t want to type.

I don’t know what prompted this blog post, but I disagree with many fundamental parts of it. Jarvis seems like a decent guy (have only met him online and not yet in person) but I think Jarvis is making a mistake that many people (not just software developers) make: thinking that the rest of the world should think like you when it clearly doesn’t.

Initially I was going to make a point-by-point takedown of his blog post, but halfway through it I realized I was being an asshole. So instead I want to discuss where I think he’s wrong.

I mentioned on Twitter to Jarvis that it’s just as important to work on your co-workers as all the other things you do. He said two interesting things in response:

• “This is what I don’t like about big companies”
• “I work on computers, not people”

First, I’ve worked at places both big and small. There is nothing inherently better about either type. Do not kid yourself thinking only great things happen at small companies. Great things happen when groups of smart people get together and are given permission to go make it happen.

I’ve seen it work at large places where managers “ran interference” so their employees could make stuff happen. I’ve seen small places stifle creativity in their employees out of fear of change.

It’s not the size of the company that matters, it’s how they choose to work together that matters.

The second point is the one where I think Jarvis has made the biggest mistake in his approach.

We work FOR people USING computers. The computer is a tool to achieve a goal. Those goals are achieved by working with others, whether you wish to believe that or not.

As someone who has worked from home for a long time, I understand and sympathize with many of the things Jarvis indicates that bug him. Noise from co-workers, drive-by meetings, feeling pressure to participate in social activities.

But at the end of the day, to accomplish anything of substance requires me to interact with others in REAL TIME. I have proven that I can both get work done AND not be such an asshole that others choose to ignore the remote worker instead of working hard to integrate me into the team.

I find that socializing with my co-workers is a good way to learn about the people I work with, so that when I need something from them later they are less likely to say “why the fuck should I help that guy?” I need their help as much as they need mine.

Of course, I don’t think this bit at the end helps much:

I am extremely productive in this setting. For five years I have cranked out more code in this room than many people have written in their entire careers.

I am exceedingly good at my job and I am sick of being told that my lack of cultural involvement makes me a bad employee.

mic drop

Disrespecting co-workers isn’t always the smartest move. Failing to understand why others think that being aloof and distant and insisting that results matter more than how you treat people isn’t always the smartest move either.

Tech is not a meritocracy, despite our wishes for it to be. Jarvis, you’re not alone in wanting people to just leave you the hell alone so you can get some work done. I am that way many times, but I make sure to create those bonds with my co-workers so that the amount of time that I spend with them is enjoyable instead of resenting the time there.

Nothing creates bonds of friendship like a shitty job, but being friendly with your co-workers costs you nothing but a little time, time you’re probably spending doing horrible things like reading the comments on Hacker News.

I haven’t done one of these blog posts in a while, so I thought I would solicit some ideas from my Twitter followers and address a few of them.

Can I unit test in 140 characters or less?

No. Testing, in general, does not lead itself to brevity. The tools we use to test our code in an automated fashion can only abstract so much away from us before we actually have to write some code.

Large amounts of setup work is a sign that perhaps your code-under-test is doing too much. Sometimes it is unavoidable if you are using dependency injection to create multiple dependencies.

Of course, “large” is also subjective. I would offer my opinion on what “large amounts of setup work” means to me, but that would just lead to people arguing with me about testing when I’d rather argue about why dick jokes spoken at conferences are the tip of the metaphorical iceberg that represents white male privilege in the tech industry.

sigh

What are your favourite Vim plugins?

I group the plugins I use into two categories: “essential” and “everything else”. Right now, I only have four essential plugins:

• Pathogen for organizing my plugins
• Supertab
• Syntastic
• Surround.vim

All other plugins swap in and out depending on my mood and whatever problems I am attempting to solve in code. Right now I’ve got the following

• Closetag
• Ctrl-P
• NERD Commenter
• NERD Tree
• pb.vim
• Vim CoffeeScript
• Vim Git Gutter
• vim-javascript
• repeat.vim

Is Grumpy Cat your Cat?

No.

Life as a unicorn in Canada

This was asked tongue-in-cheek by my boss, who refers to me as his “Canadian unicorn” because of my unique status within the company but I think it’s actually better re-framed as “what is it like working in a senior role when you are remote?”

First, my co-workers go to great lengths to make sure that myself and the two other remote workers in a group of over a dozen (I cannot remember all the people who are on the other team that makes up our group) are integrated into all decisions.

We have been experimenting with using Google+ Hangouts as a way for all the remote workers to see what’s going on in the office. Despite my initial reservations that it’s simply a way for nervous management to keep an eye on us I think it has worked out well. They’ve created a permanent “remote station” and people have walked up to it to find one of us and ask us directly a question.

It’s growing on me, and I have also started looking at this awesome site on making remote pair programming smoother for inspiration on how to make it better. I already use my iPad as my “personal device” while working from home, so it seems natural to start using it as my visual gateway into the office.

Second, because I am remote and therefore trusted to work for long stretches of time with Eyeball Supervision (a.k.a walking up behind you and asking what you’re working on) you get assigned tasks that can be done by one person (sometimes two if the other can be dedicated to the task) and take a while to do.

Unless you make the commitment to do remote pair-programming (which I have done with great success) you should get used to working on stuff in a directly-unsupervised fashion.

This suits me just fine.

Finally, make sure that everyone who has to work with you knows that just because you are remote does not mean that you are unwilling to do one-on-one communication with people. I have a soft phone that work has provided me, and I get phone calls from co-workers asking me stuff. I do Skype calls and lots of text chats.

In other words, I probably talk to my co-workers about work-related stuff as much as anyone else in the office.

What I miss out on are the social events that happen. That sucks, but I always make sure to do something at my end (and expense it ;) ) very similar to what my co-workers are doing. If they get pizza during a tech presentation, I make sure to order myself something similar.

Remember, being remote does not mean that you are invisible.

Productivity and task management tips

How does this grumpy guy get things done while working remotely?

• pay attention in meetings so that you are not forced into positions that are untenable for you
• work hard to get everything done that you have promised to do
• work hard to communicate with everyone because you can’t just walk over to their cubicle / office to bitch at them for not getting stuff done on your own schedule

That’s it really. Get stuff done, do good work, and there will be fewer and fewer excuses for your employer to prevent others from reaping the rewards of your trail-blazing efforts.

A Day in the life of a Grumpy Programmer

• woken up at 6am by the Office Manager, who is seeking cat treats for himself and the HR Manager
• lay in bed in a daze until 6:45am when my wife is showered, dressed and heads downstairs.
• wake kids up at 7am and putter around getting breakfast and lunches together
• throw kids out of the house between 8am and 8:15am so they are not late for school
• have breakfast, work out, shower and start my day

For the rest, just follow me on Twitter to get a feel for my mood. ;)

I did some research 30x500 style, worked on my pitch while writing the book, and on March 4th I launched “The Grumpy Programmer’s PHPUnit Cookbook”.

This book is a collection of the most common tips and techniques I use myself to write effective and quick tests for PHP code. If you’ve ever wondered how to create mock objects, or wanted to know how to test code that uses remote API calls, my book will help you.

As my way of saying thank you to those who read my blog, you can use the code GRUMPYFEED to get $5 off my book for the next week.

As always, I welcome your feedback via email (chartjes@littlehart.net) or Twitter (@grmpyprogrammer).

“Programmers are a cowardly, superstitious lot”

Programmers often look to external sources for validation of all sorts of things they do. Did they choose the right language? Are they writing good code? Will they be accepted by their peers.

Of course, there are those who are leaders within a community. Those who manage to do great things but with an idiosyncratic way of doing things. Let’s call these people shamans. In many ways programming is a mystical thing: you conjure up solutions to problems using tools that often require strange incantations.

For those who pay attention to the workings of the PHP community you might have heard about the “PHP Standards Recommendations” that have been coming out of the PHP Framwork Interop Group.

It’s first contribution was PSR-0, which covers recommended standards for autoloading of PHP code (no more remembering to require/include files any more to load your class files), then followed by PSR-1 (which covers basic coding standards) and PSR-2 which is about a coding style guideline.

More recently this group has been working on a standard for logging interfaces called PSR-3.

I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

Standards that are enforced by the community have a power that people really don’t understand. The classic example of this are the Python Enhancement Proposals. They cover a incredible range of ideas and concepts that a Python developer needs to worry about.

PEP-8, which covers coding standards, is probably the one most casual Python programmers are familiar with. The whole community followed it, which might have been easier due to Python’s use of significant whitespace. But more importantly, it was championed by Python’s Benevolent Dictator For Life, Guido van Rossum. He was able to use his soapbox as the guiding force behind it.

PSR-1 and PSR-2 are generating a lot of, well, pissing and moaning from people. I get it: I often grind my teeth when looking at code written in a style that deviates quite a bit from my normal coding style and practices.

However, it’s far more important to be able to understand what the code is doing. PSR-0, in my opinion, serves to standardize application layout for the purpose of making it easier to load classes you need in your code. PSR-3 (and similar interface standard recommendations) serves to allow you to integrate 3rd party code with yours a lot quicker.

Standards, soapboxes and shamans are an integral part of any programming community that wants to move forward and keep producing better and better tools and applications. Any programming language community that does not work as hard as possible to make it easier to integrate other’s libraries of code together is asking for irrelevancy.

Just for the sake of openness, here’s an awesome ASCII bar graph made with barg to show you week-by-week sales counts and numbers. I apologize for the scrolling you might have to do to see it.

Week Starting          #  Paid
2012-01-09 00:00:00-05 56 $673.06 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 
2012-01-16 00:00:00-05 29 $306.05 |||||||||||||||||||||||||||||||||||||||||                                         
2012-01-23 00:00:00-05 17 $95.00  ||||||||||||||||||||||||                                                          
2012-01-30 00:00:00-05 19 $203.50 |||||||||||||||||||||||||||                                                       
2012-02-06 00:00:00-05 17 $160.00 ||||||||||||||||||||||||                                                          
2012-02-13 00:00:00-05 7  $73.05  ||||||||||                                                                        
2012-02-20 00:00:00-05 14 $162.2  ||||||||||||||||||||                                                              
2012-02-27 00:00:00-05 7  $89.71  ||||||||||                                                                        
2012-03-05 00:00:00-05 6  $69     ||||||||                                                                          
2012-03-12 00:00:00-04 7  $70.93  ||||||||||                                                                        
2012-03-19 00:00:00-04 15 $128.67 |||||||||||||||||||||                                                             
2012-03-26 00:00:00-04 55 $356.97 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||   
2012-04-02 00:00:00-04 11 $131.00 |||||||||||||||                                                                   
2012-04-09 00:00:00-04 1  $8.50   |                                                                                 
2012-04-16 00:00:00-04 25 $277.30 ||||||||||||||||||||||||||||||||||||                                              
2012-04-23 00:00:00-04 16 $157.83 |||||||||||||||||||||||                                                           
2012-04-30 00:00:00-04 8  $95.00  |||||||||||                                                                       
2012-05-07 00:00:00-04 7  $81.50  ||||||||||                                                                        
2012-05-14 00:00:00-04 8  $75.04  |||||||||||                                                                       
2012-05-21 00:00:00-04 13 $43.00  ||||||||||||||||||                                                                
2012-05-28 00:00:00-04 2  $21.50  ||                                                                                
2012-06-04 00:00:00-04 19 $149.41 |||||||||||||||||||||||||||                                                       
2012-06-11 00:00:00-04 8  $74.42  |||||||||||                                                                       
2012-06-18 00:00:00-04 10 $92.00  ||||||||||||||                                                                    
2012-06-25 00:00:00-04 7  $30.00  ||||||||||                                                                        
2012-07-02 00:00:00-04 11 $104.08 |||||||||||||||                                                                   
2012-07-09 00:00:00-04 14 $157.47 ||||||||||||||||||||                                                              
2012-07-16 00:00:00-04 3  $26.99  ||||                                                                              
2012-07-23 00:00:00-04 3  $34.50  ||||                                                                              
2012-07-30 00:00:00-04 11 $120.50 |||||||||||||||                                                                   
2012-08-06 00:00:00-04 4  $43.00  |||||                                                                             
2012-08-13 00:00:00-04 10 $108.00 ||||||||||||||                                                                    
2012-08-20 00:00:00-04 4  $47.50  |||||                                                                             
2012-08-27 00:00:00-04 7  $82.00  ||||||||||                                                                        
2012-09-03 00:00:00-04 6  $55.50  ||||||||                                                                          
2012-09-10 00:00:00-04 6  $464.98 ||||||||                                                                          
2012-09-17 00:00:00-04 6  $62.01  ||||||||                                                                          
2012-09-24 00:00:00-04 3  $34.50  ||||                                                                              
2012-10-01 00:00:00-04 5  $61.40  |||||||                                                                           
2012-10-08 00:00:00-04 55 $624.92 |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||   
2012-10-15 00:00:00-04 21 $218.78 ||||||||||||||||||||||||||||||                                                    
2012-10-22 00:00:00-04 16 $169.50 |||||||||||||||||||||||                                                           
2012-10-29 00:00:00-04 6  $105.00 ||||||||                                                                          
2012-11-05 00:00:00-05 12 $120.00 |||||||||||||||||                                                                 
2012-11-12 00:00:00-05 4  $43.00  |||||                                                                             
2012-11-19 00:00:00-05 10 $112.02 ||||||||||||||                                                                    
2012-11-26 00:00:00-05 9  $101.25 |||||||||||||                                                                     
2012-12-03 00:00:00-05 15 $159.00 |||||||||||||||||||||                                                             
2012-12-10 00:00:00-05 6  $72.30  ||||||||                                                                          
2012-12-17 00:00:00-05 13 $142.03 ||||||||||||||||||                                                                
2012-12-24 00:00:00-05 4  $38.50  |||||                                                                             
2012-12-31 00:00:00-05 1  $13.90  |                                                                                 

What am I disappointed about? I think, to use the old expression, I left a lot of money on the table. I could’ve charged more for the book, but this was before I started learning more about the marketing of info products and how to do research to find solutions to problems people are experiencing.

Setting that aside, I think my Testing Crusade is paying dividends for the community as a whole. The more developers who are exposed to the ideas that people like myself are promoting, the higher quality code that is likely to be produced.

If you’re a customer of mine, thanks so much for supporting my efforts through your paid contributions. Writing automated tests and code that you can easily test doesn’t have to suck. I can show you how to do it, and I look forward to bringing you more of it in 2013.

If you believe in the power of TDD, then the answer is “you write tests from the beginning of the project and forever after.” I am a believer that TDD can be a very powerful design tool for building things at the unit / module / component level.

Then some people asked me my thoughts on the comments by the creator of the Rails project about the usefulness of dependency injection. As happens when I am feeling frustrated, I started firing out the tweets on my feelings on testing and the lonely Crusade that I am on.

Then I saw a talk by Dan North called “Decisions, Decisions” at the recommendation of Ian Barber that made me realize that someone else has articulated my feelings on when you should be doing testing. Slides for the presentation can be found here.

You should watch the whole presentation. So many decisions about programming are made without understanding, REALLY understanding the trade-offs involved when making one decision vs. another.

Let’s look at TDD vs. Test whenever. The trade-off being made here is not about quality of code or guarding against regressions. It’s about opportunity cost. This had occurred to me but I had dismissed it as being “anti-testing”.

But I think I was wrong, and here’s why.

In that awesome presentation he talks about “patterns” he observed on the team he was working with at the time. He was amazed at how much work this team was getting done, so he spent time analyzing what they were doing and trying to turn some of their activities into patterns of behaviour. Repeatable processes are good, right?

The one that he saw being related to writing was a pattern he called “Spike and Stabilize.” Basically, you write code without any tests until it becomes a solid part of your application’s architecture. Once this code has proven it’s usefulness, you start writing comprehensive tests in order to verify that it is in fact doing the job and doesn’t break going forward.

This is so obvious to me now. Clearly, you are leaving yourself open to the potential of writing not just application code but testing code that gets tossed away if the idea you are implementing is unable to prove it’s value.

Opportunity cost is huge and often dismissed by developers too. If you have some prototype code, or even functionality with a half-life measured in 3-month-increments, what else could be worked on while tests for this code are being written?

Could this hybrid approach be an easier sell to skeptical managers or other stakeholders? That’s hard to say. The “too busy to write tests” camp still has many members, and is still seems that it takes catastrophic failures before many people join the Testing Crusade.

To be perfectly clear: I find great value in prototyping code and then committing to tests once the prototype is ready to move to a more stable environment.

I try and do prototyping before I commit to writing code, because I often feel that way. My prototypes are usually command-line scripts that try and accomplish the task I’ve been assigned. That way, it’s easier to actually write some tests once I know what I’m doing and guard against regressions later.

The key to all this is being able to identify at what stage in this particular pattern your code is at. Is it still a spike, meaning you are working out implementation details and trying to figure out if it will even have the desired result? Or is it stable, providing solid value to the application as a whole and ready to be wrapped in tests to protect against regressions?

Next time you are thinking about “I need some tests for this”, consider the Spike and Stabilize pattern. The answer might be “you need tests…but not yet.”

I had a much different blog post written, and decided to scrap it in favour of a different approach. Buckle up, here we go, starting with January and continuing to the end of the year:

• unhappy with start-up life
• started grinding out episodes of a podcast with Ed
• released my “write testable PHP applications” book on January 11th
• spoke to a near-empty room at CodeMash 2012, they seem to not like PHP there
• started working for an online learning company
• made plans to attend PHP|Tek 2012
• found softball enjoyable this year as I could actually bend over to field balls. Still can’t hit
• did a live episode of the podcast at PHP|Tek, which was awesome
• started mentoring three developers on ways of being grumpy programmers
• found the benefits of test-centric development to be ruined by a terrible work environment
• Ed and I hit our groove with the podcast in the summer
• started looking for another job
• taught my PHP testing bootcamp course of the first time, in person though
• switched to my third job in 2012
• got accepted to speak at a conference in Sweden
• helped organize a PHP conference up here in Kanuckistan
• spoke to a near-empty room at the conference in Sweden, guess they don’t like PHP there either
• got accepted to speak at a PHP conference in Belgium
• created an online version of my PHP testing bootcamp course
• worked on my next book
• wondered what the hell happened to everything I wanted to do in 2012.

Like so many things in life, you can only plan for so much. At the beginning of 2012 the only thing I knew for sure was (a) I wasn’t liking my job and (b) my book was coming out extremely soon. At the same time I was worrying about the fact that my ENTIRE FUCKING CAREER is basically built upon the pile of web-enabled spaghetti that is PHP. What the hell should I do?

So I took some babysteps towards learning server-side Javascript and played around with Node.js. I like it, I think I am understanding how to build applications using it in a more idiomatic way.

But there is still lots of PHP. Can’t escape it, it’s all I know. Well, that and a whole bunch of actual theory on how to build web applications as small modules of code that talk to each other.

I didn’t set any goals for 2012 other than “sell $10K worth of books” and I did manage to almost accomplish that. $6,547.25 in royalties for the ebook, $2K in licensing fees and some-amount-I-have-not-added-up in paper copies of the book. I think I can say that I almost made it, and that my next book will do even better because of the success of the first one.

So what is in store for me in 2013? The plan is to keep pushing the info-products (books, courses, screencasts later in the year) while continuing to make solid contributions at the day job. There is no lack of interesting things for me to do at the day job, more than enough to keep the gears going.

I enter 2013 feeling like I’m stuck in low gear mentally, though. I’ve clearly over-committed myself and I just have to grind through it until March 2013.

I will say that I have decided to focus on becoming a better programmer, no matter what languages I tackle. I have a bunch of reading material cued up to help me get better at taking real-world problems and figuring out how to solve them in the context of programming environments and domain models.

That is the last piece that I personally feel is missing from my skill set: learning how to figure out how to turn business objectives into techincal solutions. I’m in a good spot to do it, and I know my boss has all sorts of “fun” things lined up for me to do.

So thanks for another year of watching what I do with some interest and I aim to provide you with more entertainment and knowledge throughout 2013.

As an early Christmas 2012 present to all my loyal followers, who put up with my never-ending stream of nonsense and provide a slowly-increasing portion of my income, here are my thoughts on how to get started with testing your PHP code.

Learn how to recognize untestable code

The worst feeling in a programmer’s world has to be sitting in front of a piece of code that you didn’t write yourself but is critical to the success of your business. You will be told that it’s of the utmost importance that you GOD SAKES DON’T BREAK ANYTHING OR ELSE WE ARE DOOMED.

While I don’t get the same kinds of warnings from my employers, I am familiar with that feeling of trying to figure out not only what the code in front of you is supposed to do, but what the developer who came along before you was even THINKING ABOUT in that code.

When it comes to testing code, there are two principles that you have to strive to aim for:

• find a way to pass dependencies into your code
• find a way to break down your code into the smallest modules possible

By following this two simple-but-extremely-difficult-to-do ideas, you will end up with code where writing tests becomes so easy you will be doing it without a second thought.

No more static method calls. Get rid of those private and protected methods. Stop creating new objects inside a method. Think about passing data around instead of objects. Work hard to make sure your methods have little-to-no side effects). Decouple your data source from the code that manipulates results from it. More importantly, understand why all these things are barriers to having an easily-testable code base.

In short: do all the kind of hard work and drudgery that many managers tell you is a waste of time and will not return any value to your employer. I say screw those guys and instead feel awesome about working on building light, nimble systems full of tests that let you go home from work on time.

Keep learning the language

Tests are just code. Keep learning how to write better PHP code. Understand why so much of what is on PHP Sadness is actually trying to help us get better. Understand why the array in PHP is awesome. Learn the iterator drinking game.

In short, the more you know about the language the more likely you are to learn how to solve problems using core functionality instead of constantly implementing solutions in code you wrote yourself.

Chain units of code together for greatness

I’ve talked about in other places about my thoughts on the UNIX philosophy. For the impatient, it is about creating small, single-purpose units of code and then chaining them together to accomplish awesome things.

If you’re ever searched online for ways to do things from the command line in various flavours of Linux distributions, you will understand what I mean. “Take sed and cat and awk and grep and pipe it through cut and then to sort and you will get exactly what you want.”

That sort of stuff is awesome, and fits in rather nicely with the concept of writing small modules of easily-testable code.

Start asking “how am I going to test this?”

This is the first question I ask when I am presented with a problem that I need to solve using code. From that one extremely important question all the best practices that are associated with building highly-testable code emerge from.

If it is not obvious how you are going to be able to create automated tests for a particular set of functionality, it probably means you haven’t thought hard enough about the problem you are trying to solve.

I’m not saying every problem has a testable solution. But any problem where you have expected results based on known input is a scenario that you can test for. Database queries. 3rd party API’s. Request routing. Fizz Buzz. These are all things that we can test, by making sure to follow some of those key ideas I advocated above.

Test-centric development is about using tools as a way to create API’s and interfaces that are simple, easily testable, and easy to modify going forward.

Adding new features becomes a potentially-simple process consisting of:

• design new feature
• write tests for these new features
• write code until the tests pass
• go home on time

Stop people from pushing code without proof it’s fixed

Sure, you don’t have any tests RIGHT NOW. But I’m sure you’ve got bugs to fix in your code. Write tests to verify that the bug exists. I’m sure you’ll find your code isn’t as modular or testable as you thought it was.

Once you’ve reproduced the bug, then write some code until the bug GOES AWAY. Then push your updated code into production. Rinse and repeat until you have a very highly-targeted test suite and a bunch of highly-targeted fixes for known mistakes in the application. That is what I call real-world testing.

So make sure that nothing that fixes something goes up into production, no matter how desperate the circumstances, without proof that this fix actually is a fix instead of a wild guess.

Stop people from doing things manually

It’s the 2nd year of the 2nd decade of the 21st century. The internet is full of instructions on how to automate just about anything. Spend an afternoon studying that instead of dreaming about an advertising-driven disruptive startup.

Chef. Puppet. Shell scripts. Jenkins. Travis. Virtualized servers. Learn these things. Use them. You will thank me. Maybe enough to send me money via PayPal. Automate everything that you keep finding yourself doing manually, and then figure out if there are ways to not even do those things. You might be surprised.

Stop using tools without test suites

I treat any PHP tool that does not have its own test suite as a black box that cannot be trusted. Tests show that the developer cares about the quality of the work they do, and also provides real examples on how to do things.

Black boxes are not things you should be relying on when the going gets tough. Treat any code that you cannot easily test as being suspicious and likely broken. I feel the same way about code I have written, so imagine what I must think of other people’s stuff.

Always wonder if you’re doing it right

Integration tests are a scam. Unit tests don’t fix bugs. Simple enough code doesn’t require tests. Pair programming is a cargo-cult practice. PHP sucks. Mobile applications are the future. Documentation comes after the work is done. Nobody likes a developer who asks too many questions. You work in the real world where results matter. Exit statuses are better than throwing exceptions. Asynchronous calls always result in callback hell.

Not everything in the above paragraph is true. The only way to find out is to get out there and figure out if it is true or not for yourself.

Keep on testing. I’m here to help. Merry Christmas everyone.

This past fall I taught an in-person course that I called my “PHP Testing Bootcamp” where I spent about 6 hours showing a bunch of PHP programmers how to twist their code into testable shape. That got me to thinking that I want to do more of that, as I found that process enjoyable as well.

As I also create more products I need a place for them all to live. I have books, and now a course I can teach and I am planning on producing screencasts for sale as well. With that in mind, I am happy to announce I have created Grumpy Learning, an umbrella site for all my training and teaching efforts to hang from. While you are there, please join the mailing list via the form I have up there. I promise to not give your email address to anyone else and will give you something every two weeks related to testing or share other thoughts I have.

As part of this, I will be teaching my “PHP Testing Bootcamp” course again but this time doing it online. Check out the site for the course for details, but here’s the summary:

9 tickets available to do the course with me live at $250 per student. Three session (January 3, 10 and 17) running from 9pm until about 11pm Eastern Standard Time. I’ve already sold 3 of the 9, so you might want to hurry up.

Then I have up to 50 tickets available to get just the recordings of the course for $125. If you can’t make it due to time zone differences or prior commitments, the videos of me teaching the course and answering questions is a great option. I’ve sold 2 of these, so plenty of them left.

Students who participate in the live sessions will also get access to the videos as part of their tickets.

If you’ve ever wondered how someone who takes coding and testing seriously works in a test-centric manner, this is your chance. Give yourself an awesome gift for the holiday: a chance to learn how to write testable code and the tools that make it happen.

The theme of this year’s edition of the conference was “Viva La Rebellion”. I’m guessing that they were hoping by accepting talks that seemed to fall out of the mainstream they would inspire people to want to do things differently.

In that regard, I think they can declare it a success. The content was widely varied, as you would expect from a conference featuring multiple platforms and multiple programming languages.

However, the sad reality is that, in my opinion, it’s really only the speakers who were there doing something revolutionary. I ended up spending quite a bit of time hanging around with legendary Internet curmudgeon Zed Shaw. He was generous with his time and his comments, even after he found out that PHP was my bread-and-butter.

He gave a lightning talk where he explained his own experiences in rebelling from inside a large monolithic organization, the US army, in order to prevent himself from doing something he didn’t want to do. He also brought up the point that so many people project an aura of rebellion through clothes, or programming language of choice, but still start each day by sitting down in front of a computer and essentially asking their boss “how can I make you rich today, sir?”

From my own perspective, that’s bang on. I joke all the time when on IRC that all the perks that employers attempt to provide their employees are really just things to distract you from the fact that you are a slave, a digital sharecropper. I instead prefer to work from home as a way of making my chains fit a little less snug and to not have to hear the constant rattling.

I will also be truthful when I say that my current employer treats me very well, allowing me some real freedom in terms of projects I get to work on. A shitty job is one where you little to no say in what you get to do. Been there, won’t ever do that again.

So if you have the fire that is “in your belly”, that yearning to do something more with your time than just help someone else get rich, you speak at conferences. Those are opportunities to teach people about things, to speak to other like-minded people, to really take chances and find out whether you really know what you are talking about.

More importantly, it provides a way for you to gauge your own knowledge and skills compared to those who are your peers in terms of willingness to share knowledge. I was pleasantly surprised to find that when I went to talks about technologies I don’t use, I was understanding the concepts they were talking about.

I’m only a rebel in the sense that I am attempting to popularize an approach to writing code that most PHP developers don’t use, by using automated tests to drive the design of the code. The real rebels are people who challenge pre-conceived notions within a community and then share what they’ve found. Just because you use Rails doesn’t make you a rebel. More like using PHP makes you one these days.

I did attend sessions about 2/3 of the time, the rest of the time spent either working on my PHPUnit book or just relaxing in the super-awesome speakers “cave” they set up for us.

On Tuesday I only went to a morning workshop given by Drew Neil about “Vim Mastery”. I had ulterior motives to go: I had sponsored an episode two years ago and I bought a copy of his book “Practical Vim”. After I got him to sign it I got 3 hours of good instruction on how to best use Vim by learning how to do things more efficiently. Text objects and figuring out repeatable sequences were the two big takeaways for me.

After that I hung out with a few of the other speakers and somehow a group of us who were supposed to go out on a tour of Malmo missed the bus for the tour. Oh well.

Wednesday was the first day of the conference proper, with Monday and Tuesday being just for half-day and day-long tutorials. The keynote speaker was David Rowan, who is the editor for the UK edition of WIRED magazine. Lots of talk about how technology is awesome and how the world has been changed by software, and how software will be used to help solve some really tough problems going forward.

All I could think of was the future is already kind of looking like this.

I skipped the first set of talks to work on putting the final touches on my own presentation that was later in the day and then watched /dev/hell guest Justin Searls give a talk about the value of mock objects in your tests. Justin is an awesome speaker, despite his protests to the contrary and presented a very compelling set of strategies for using mock objects in your tests.

My favourite part of the talk (besides the end, HAHAHAH just kidding) was where he talked about mocking anti-patterns. Yes, there is such a thing as using mocks incorrectly. You can check out the talk here.

After lunch I sequestered myself again to make sure I was ready to give my talk, and then popped up at 3:45pm to give my talk. Yes, it’s true, there were only 5 people in the room for my talk. PHP is not popular in Sweden and I was also up against some good speakers, including the creator of Jenkins. These things happen, but my talk was recorded for anyone who was not there to see.

After my talk I stuck around to watch Konstantin Haase from Travis-CI talk about what they do at Travis and provide a little bit of insight into the challenges they face in running a Continuous-Integration-As-A-Service application.

Finally, at 6pm there was a closing keynote by Jim McCarthy, one of those guys who kept popping up at key points in the history of software development and he talked about his experiences leading the team that ended up building Visual C++.

He went on to talk about how he and his wife have devoted a number of years now to studying how groups of developers work and on techinques that can be applied to help them get more interesting work done. Not that he shared many of them as that is how he makes his living.

Can’t say that I agreed with his statement that the fact that people in China were banned from seeing Facebook and Twitter was “no big deal”. I had expected to hear more stuff about “culture hacking”, but maybe I just had some preconceived ideas as to what that really meant.

Then I had dinner and drinks with some of the other speakers, and went to bed happy that I delivered what I thought was a good talk.

Thursday’s opening keynote was by fellow Canadian Reg Braithwaite where he really talked about rebellious people, and the 4 most common roles we find within any marketplace of ideas: Leader, Rival, Innovater, Everyone Else. Fascinating analysis of how people’s refusal to understand these four roles leads to much unhappiness and even how entities move from one role to another.

Again, I highly recommend watching the video

Next I went to Fred George’s talk on Micro-service architectures, where he talked about how he led a team that went to extremes while building a service-oriented architecture, by creating services so small (on the order of 100 lines of code) that some of the concerns about unit testing and versioning just went away due to size.

I have my own concerns about how to scale something like this, but it provides a valuable lesson in really breaking down functionality of services into the smallest pieces possible and then monitoring services to make sure they are being used. Sort of like a survival-of-the-fittest contest for services, giving developers the freedom to create multiple versions of services, running them at the same time. Being so small, the cost of rewriting them, even using a new language, was minimal.

Next up was a talk on automated testing strategies for databases. It’s rare that I see a talk that really disappoints me. This was one. Nothing new, nothing unconventional, nothing that a few people with more than a couple of years’ experience using databases could not have come up with.

After lunch I watched a talk about the Event Store and felt weirded out by the talk. I wasn’t quite sure what it was for, what problem it was solving, and the whole talk felt like a very smooth and practiced sales pitch for a commercial technology. Yes, they had some impressive stats in terms of how it performed on the presenters laptop but I came out of that talk not really understanding what it was for. I also was 99.999% certain that one part of the demo was completely faked. The presenter entered some data into a form for an online chat application built with it, and what was displayed on the screen did not match AT ALL what he had typed in. Very strange.

Next was a series of lightning talks. I sat in the set from Hampus Jakobsson (talked about learing if you really loved something by doing it every day for a month and then giving it up), Chris Hughes (talked about his experiences with really doing things the way he wanted and not caring about the consequences) and then Zed Shaw talked about why none of the attendees to the conference were really rebels.

Finally, I watched Steve Klabnik talk about building Hypermedia API’s. I think that anyone who is designing an API they really expect people to use should watch the talk to get a feel for how tough a task it is to really build one.

The next talk was “Why Mud Rules” by Brian Footer. Brian talked about the tendency of code to become a big ball of mud, and why that offends so many developers. The money quote in his talk was “What do you call people who ship big balls of mud? Millionaires.” It’s a reminder that shipping still matters, even if the code is terrible in quality.

I had dinner with Felix Geisendörfer and Drew after this talk and spent more time hanging out with Felix while he hacked on the code for controlling his drone.

On Friday, what could’ve been an interesting keynote by someone working extremely hard to get fibre and high-bandwidth internet connections to homes around Sweden was wrecked and cut short by the MC, who wasted a lot of time on an audience participation stunt. Also a diversion into Swedish rape laws was unwelcome.

After the keynote I watched Felix give a talk about Node.js by demonstrating the library he had written for controlling his AR drone quadcopter using Node.js. You have not really been to a conference until you’ve watched someone fly a drone using cURL CLI commands that speak to a web server RUNNING ON THE DRONE.

After that I sat in Denise Jacobs’ talk about sparking creativity, and some techniques for getting yourself into The Zone, The Flow, whatever you want to call that state where you can be really productive. Lots of good reminders on removing distractions and obstacles to being productive at work.

Following Denise’s talk, I went to José Valim’s talk about Elixir, which is a Ruby/Python style language that sits on top of the Erlang VM. It looked very interesting to me, definitely worth checking out for potential future use in applications where concurrency become an issue. Plus you can drop down into the weirdness that is Erlang when required.

After that I just kind of hung out with people in the speaker area, having some great conversations with all sorts of people, until it was time for Hojun Song’s presentation about his project to send an open source satellite into orbit. I have to admire his persistence, and how he’s financing the project by selling t-shirts! I was going to buy one, but he was not selling one in my size…

Then the conference was over. One last dinner with the speakers I had met and then I spent Saturday doing a day trip with Reg Braithwaite to Copenhagen to meet with two new friends who are PHP devs working in Copenhagen. Christian and Jose were awesome hosts as they led us on a walking tour of the city. I also found out just how expensive alcohol really is in Northern Europe. Two Irish coffees with double shots of whiskey: CDN$40. Yikes.

All in all, I had an awesome time.

Even though I was the only PHP talk at this conference, I realized that I understood a lot more about programming than I realized. So much is transferable across languages and platforms. Go to conferences like this to broaden your skill set, to check out how users of other languages are solving problems, and you cannot stop from becoming a better programmer.

Øredev treated me very well, and I would consider going back again to speak if my future plans allow me to fit it in.

Please, PLEASE check out the recordings of the presentations they have made available. Not every presentation is there yet, but they have plans to make them all available under a Creative Commons license.

I think that we are witnessing the first wave of new testing tools in the PHP community that allow developers to wrap their applications in automated tests.

I am familiar with the BDD-style that is being promoted in PHPSpec, through my work with Behat to create automated user acceptance tests. I think if you want a tl;dr version of PHPSpec I would tell you “write hybrid unit/integration tests using plain language”.

The concept that is being promoted is “SpecBDD”. It means “writing tests to a specification and then writing code until that specification is met.” Not a lot different than writing tests using tools like PHPUnit.

Your still going to have to write code that you can test if you want to use phpspec. That means you still need to know about dependency injection and other characteristics of testable code. Sorry, no magic testing pixie dust here.

I was also surprised to see the use of mock objects, which are being called “Prophet Objects”, but that means that you can really write specs that test for things in isolation.

Mock objects are, in my opinion, the conceptual stumbling block that developers need to get over in order to really, deeply understand how to write effective tests. I am happy to see phpspec promote this idea and provide a fairly simple API to do it.

The process is the same as it would be if you were using PHPUnit: write the test / spec, and write the damn code until everything passes. Again, no magic testing pixie dust.

(By the way, if someone makes me a “magic testing pixie” t-shirt, men’s size XXL or larger, I will purchase it YESTERDAY).

Keep on cranking out the tools, make them useful for people OTHER than testing zealots to use them, and you have yourself an unstoppable wave of automated testing.

I am intending to write some code to act as an API for the site that runs my simulation baseball league and refactor the existing PHP code to consume that API instead of speaking to the database through CakePHP (really OLD CakePHP at that too) models.

So, it took me a while to search around and find enough information to create my first integration test. In the end, the stack is Mocha to do the testing, with SuperTest to handle all the HTTP testing.

So, the app itself is built on Express and talking to a Postgres database using node-postgres. It seemed to me that express was the best solution for a newcomer to Node but familiar with MVC / modern web application paradigms.

So, let’s take a look at some of the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

// Front controller for our API

var application_root = __dirname;
var express = require("express");
var path = require("path");
var pg = require('pg');
var app = express();
var model = require('./transactionmodel');

// Create our database connection
var connectionString = "pg://chartjes:@localhost:5432/ibl_stats";

pg.connect(connectionString, function(err, client) {
  if (err) {
    console.log(err);
  }
});
var client = new pg.Client(connectionString);
var tm = new model.TransactionModel(client);

// Config things we need to get the app going
app.configure(function() {
  app.use(express.bodyParser());
  app.use(express.methodOverride());
  app.use(app.router);
  app.use(express.static(path.join(application_root, "public")));
  app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

app.get('/transactions/archived', function(req, res) {
  var done = function (err, transactions) {
    if(err) {
      res.send("Error querying transactions", 500);
    } else {
      res.send(transactions);
    }

  };

  var currentTransactions = tm.getArchived(done);
});

app.get('/transactions/current', function(req, res) {
  var done = function (err, transactions) {
    if(err) {
      res.send("Error querying transactions", 500);
    } else {
      res.send(transactions);
    }
  };

  var currentTransactions = tm.getCurrent(done);
});

module.exports = app;

I am also using the awesome Postgress.app while working on this app on my laptop.

One of the things I learned while I started to build my tests was that if I wanted to test stuff in isolation, I needed to alter things slightly and export my Express “app” as a module instead of including the command necessary to make it run and listen for requests on a specific port.

Now, I did find some blog posts about how to write integration tests, but they either wanted to use CoffeeScript or was using custom modifications to the testing tools. I am not familiar enough to write stuff like that (not in JavaScript anyway) so out of frustration I looked at the source code of Express since this blog post mentioned how he created a custom version of something used to help in testing.

When I looked at the source of Express, the author had replaced a bunch of stuff with code that simply imported SuperTest. I think I swore really loudly at myself for not looking sooner.

Armed with the knowledge that I had my missing piece for the integration test, I wrote a simple one.

1
2
3
4
5
6
7
8
9
10
11
12

var app = require('../app');
var request = require('supertest');
var assert = require('assert');

describe('Transaction API', function() {
  it('GET /transactions/current should return 200', function(done) {
    request(app)
      .get('/transactions/current')
      .expect('Content-Type', /json/)
      .expect(200, done);
  });
});

It worked, which is the first step. How about another test? Let’s make sure that if we do that call to /transactions/current and verify that we are getting back a result we expect

1
2
3
4
5
6
7
8
9
10

it('GET /transactions/current should return expected results', function(done) {
    var fs = require('fs');
    var currentData = fs.readFile('./current', 'utf8', function(err, data) {
      if (err) { throw err; }
      return data;
    });
    request(app)
      .get('/transactions/current')
      .expect(currentData, done);
  });

For this test, I am reading in a text file that contains, for a known database, a JSON representation of that data. Then I do a call to my API call, and compare the result I get back to my fixture. Just like any test I would write in PHP. Compare the expected to the actual.

In episode 21 of /dev/hell I talked a bit about how I felt that testing skills from one language are transferrable to another. I think the fact that once I figured out that SuperTest was the missing tool, it took me less than 30 minutes to write those two tests. That includes research time reading the documentation for both Mocha and SuperTest.

More tests are sure to come, but I think I’ve found the right set of tools for the time being.

Having written a book that shows you how to write code that is testable it seemed natural to write a companion book for that, to give people a better understanding of how to use some of the testing tools.

To that end, I’ve started working on “The Grumpy Programmer’s PHPUnit Cookbook” to be released in early 2013 (I’m thinking end of January / beginning of February if everything works out).

The book will be a collection of tips and tricks on how to use the gold standard of PHP unit testing frameworks, the mighty PHPUnit. If you visit the website for the book you can join a mailing list to be notified when the book is ready.

By joining that mailing list, you will also receive some goodies along the way as the book gets written. No, I’m not going to tell you what they are.

The book will be $25. No, I don’t know how big it will be. Maybe you will end up paying $1 per page, but let’s hope not.

The book will also be published through Leanpub as I am 110% happy with what they have done for me, and I encourage anyone else who wants to write their own technical book and keep most of the money from their efforts to consider using them.

I do have friends who appear to be bottomless sources of happiness and good cheer, their Twitter feeds full of positive messages to all. That is not my path, but not for the reasons you might suspect.

I seem to generate a lot more feelings of “satisfaction” than outright “happiness”. I also think, that being an agnostic person when it comes to organized religion, that I don’t put a lot of stock in prayer or “the power of positive thinking” and other related things. I also believe that Fate and Destiny plays a big role in people’s lives, and while we are in control of our day-to-day lives, you are moving down a pre-destined path in the greater scheme of things.

My mother (a retired high-school teacher) always told her students that they are “not losers, but choosers”. When my thread has played out to a point where it intersects with someone else’s, I always have to make a choice. So don’t think I am a fatalist who believes all is pre-ordained. I believe a wise person once said “luck is the intersection of opportunity and skill.”

Not that I believe I am destined for greatness in any way. My programming skills are not in the field of inventing (or reinventing) awesome pieces of technology for the greater good of all. I am more the type that likes to combine things together and figure out how to make something BETTER come out of all of it.

Hence my like for testing, and codified programming practices for a given language. How I like to go to conferences, and organize meet-ups, and take time out of my after-work schedule to just shoot the shit over Skype with people who are willing to toss away the grumpy cartoon character I play on Twitter to talk to the person underneath it.

So, not a lot of happy thoughts come out of me, more like “man, I am glad this shit worked out in a way I am satisfied with”. Satisfaction IS what I aim for, because my wife can tell me that I am my harshest critic, holding myself up to a pretty high standard for whatever tasks I tackle when I am confident I can do a good job.

You can be happy. I’ll be over here feeling satisfied.

Thanks to the icon of the PHP community for the topic suggestion.

Along the way I have learned some valuable lessons about the process, and at the same time have been getting some great insights via Amy Hoy’s “I cannot stop telling people who want to build their own things to go plunk the money down for it” 30x500 course.

So has my book been a success? That depends on your point of view. Initially I said I would be happy if I doubled the number of sales of my first book. That would mean pulling in almost $5000. I gave myself a year. With this licensing agreement, I have passed that number in 8 months.

But I always felt that while I was a pretty decent programmer and also good at expressing my ideas to other people, I was missing something. That something is MARKETING, folks. I was confident that I could write a book that people would want, I just didn’t have the skills to convince people of that.

In a way, I was partially right.

I built up interest via social media. I promoted the book at least once a week, almost always resulting in sales within minutes of the messages. I gave away copies to user groups, who in turn promoted my book for me and that also resulted in cool conversations AND book sales.

I don’t mind putting in the effort to promote my book this way. How else are people going to know about it if I don’t share? Yes, making money off of it is good. I was more concerned about making sure people knew there were ways of making their lives as PHP programmers easier. Testing doesn’t have to suck.

It felt good, and money was coming in. While I slept, and it was cool to wake up every morning to emails from my publisher telling me that someone had bought my book.

But it wasn’t enough. I felt like I could be making more money from my efforts. I’ve been selling copies of my book at a pretty consistent rate since the first big push when I launched, but that got me hungry for more. More books. More courses. More training. More anything that can convert what I know into money that I can then use to work for myself.

That’s where Amy’s course comes in. If you take it, you WILL LEARN HOW TO MAKE IT HAPPEN. Amy shows you how to find audiences and figure out what’s causing them pain or what they need to make more money. Amy also has an awesome collection of alumni who also step up and share what they learned as well.

Here’s the catch though: you have to do the work yourself. There is no magic. You are going to work, and work hard. But at the end of it you are going to be armed with the ability to go out there and build stuff that people will be yelling “SHUT UP AND TAKE MY MONEY!” at you.

Isn’t that what you want?

If you can’t view the video because you’re on a device that doesn’t support flash, or you want to view it offline later, then you can view it here

I’ve been programming computers since I was 10 years old. That’s 31 years and counting. I had my first paid programming job at age 15, when I created a program for my mother’s private school to display a salary grid based on numbers they entered via the program itself, written in Apple basic. Sadly, there was no testing framework available to me.

When I went to community college, it was before the Rise Of The Internet. I had net access and an email account, but there was no graphical web browser I had access to. I remember seeing something called “Mosaic” on the desktops in the computer labs, but I did not have access to it. So I surfed, hard core style, using Lynx. Yes, I am that old.

Challenge 1: get an IT job

Once I was done with school, I landed a job working for a company that produced fully-licensed CD compilations for professional DJ’s. I was their “IT guy” but ended up building my first web app: an online searchable catalog that used MySQL. I wrote code that imported a CSV export from Microsoft Access and then built a form to let people search for stuff. It sort of worked. I didn’t know about wild card searches or Soundex but I was pretty proud of myself.

• learned PHP
• learned some MySQL
• discovered I still liked programming

Challenge 2: get a programming-only job

When that job ended, I found a job with a company that was using some programming language I had never seen before, and haven’t seen since. I also got to use PHP to build an online shopping store for a specialty retailer.

Everything went well…until it didn’t, and people who weren’t stock holders (it was a publically-traded company) got the boot.

• learned more PHP
• learned to work as part of small team
• failed the political office game

Challenge 3: Get a job on a bigger team

After that job, I got to sit on my couch with my infant daughter and watch 9/11 happen in real time on my TV. A few months later I got a job working for a company that dealt with online adult content and wanted to build a dating site. The company still is around, and it’s not hard to google around to figure out who it is. It is a different place now, but when I worked there I committed the first line of code for the project into a CVS repository.

It was a great education in what it takes to build a scalable PHP application, but my attitude was terrible while I worked there. I was argumentative, belligerent, and basically acted like everything that was done that I disagreed with was the worst decision ever. I learned what it was like to work on a large team, and I learned again that getting along with your co-workers mattered when it was time to do things you really wanted to do.

I lost the political game, and lost it hard. My own damn fault, to be sure.

• learned even more PHP
• used my first MVC-style framework (Mojavi!)
• first exposed to unit testing
• first exposed to virtual envrionments for dev work (BSD jails!)
• learned that I needed to pay attention to the political game

Challenge 4: Go someplace you feel you’re wanted

After leaving that job, I took a job working for a company that owned a network of online forums for sports and auto enthusiasts, along with publishing several auto magazines. Terrible fit, never got to do anything except play with CakePHP and start really blogging more. My blogging while working there led to me getting my next job…and every job since.

• learned how to do technical blogging
• learned how to contribute to an open source project (CakePHP)
• learned epic trolling skills on a mailing list

Challenge 5: Work from home

After leaving the forum job, I bounced through two jobs (left one cuz funding was pulled, left the other due to severe personality conflict with boss) and landed my first serious telecommuting gig working for a sports data integration company. I was sick of the long commute (90 minutes in the morning, two hours home) and held out for a job where I could work from home.

Loved the job. Lots of freedom to build things the way I saw fit, with a few constraints of language and associated tools (had to be ones we where using already). I also started ramping up the blogging, and grew my reputation through speaking at conferences and trying to find people I could always learn things from.

I also learned that when you build things for customers, you really should try to talk to those customers as much as you can to understand how to build what they want.

• learned some Python
• learned how to work remotely without someone needing to check up on you
• learned how to explain technical things to non-techincal people given a proper context
• learned how to self-promote on Twitter and build your “brand”
• learned how to get accepted at conferences
• learned how to get mad about getting rejected to speak at conferences
• developed ridonkulous levels of confidence in both my own skills and my abilities to find jobs I want to do
• started co-organizing a PHP user’s group in Toronto

Challenge 6: Find a job doing what you want to do

Potential NFL and NBA strikes had me nervous about my awesome-to-work-for employer going under, so I jumped ship and joined a start-up that was focussing on ecommerce within social media tools and networks. I liked the guys I worked with, but felt out of place: the things I was passionate about (best practices and testing) weren’t a good fit for the place they were in (OMG WE HAVE TO BUILD THIS THING AND GET IT LAUNCHED) so after a personally-frustrating year I left to join a place doing the types of things I wanted to do.

• learned how to wrap tests around reluctant code bases
• learned how to write an ebook
• learned how to do a podcast about programming issues
• started organzing a PHP conference in Toronto

Challenge 7: Keep finding challenges

Which of course leads me to the present. I’m now doing the type of coding work I want to do: focusing on testing practices, researching tools to improve our developer work flow, and also branching out in the outside world to helping more developers be aware of just how valuable adding good testing practices to your skill set could be.

You can see all the challenges I put in front of myself, and how things didn’t always end up the way I had hoped. If I can overcome all this stuff, imagine what you can get done! There will never be a better time to get involved in building stuff for the web. You are spoiled for choice on tools, languages and opportunities.

Don’t be scared. Be excited. It only gets crazier from here on out!

Share them in the comments!

Space is limited (15 students), so act fast and I hope to see some of you there!