This Job Is Better Than The One You Have Now

I’m not a guy who does hype, so I’m going to lay it out straight: You’ve got a job right now as a PHP guy? Leave it and come work for me at Parchment.

It has better pay than you’re getting now.

It has better hours than you’re working now.

It has better management than the place you’re at now.

It has a better mission than the one you have now.

Where you are now, a lot of stuff is solidified in place, and your attempts to improve it are not valued. Here, you’ve got a chance to get in and do stuff right. Where it’s not right, you’ve got a chance to change it and make it right. (But this is not a chance to evangelize your preferred framework.)

You’ll have me as Architect on the PHP side. For some folks that’s a deal-breaker. For most people who actually have had me as a boss before, that’s a bonus. (I can provide references from previous employees on request. 😉

The boring “help wanted” ad only says so much. Here’s the skinny:

The codebase is a typical PHP codebase. Some of you know what that means. I have already stripped out all the uses of globals. The job is to update it to PHP 5.4, design patterns, and a modern architecture, and add features as we go, while keeping the whole thing running. There are no tests; you will be refactoring to testable units. There is no standard development environment; you might be able to help us create one.

If you live in or near Scottsdale AZ and can be in the office on a daily basis, that gets a preference; otherwise, a telecommute for the right fit is perfectly acceptable. (If you live in Nashville TN we can telecommute together once in a while.)

You need to actually know PHP itself for the simple things. I don’t care if “the framework does that for you” — at the very least, you should know what the framework is actually doing under the hood.

If you blog about PHP, speak at PHP conferences, attend PHP conferences, help others in IRC or on mailing lists with PHP, work on an open-source project where there is at least one other significant contributor, and/or have a Github account where I can see your PHP code, so much the better.

The initial phone interview will consist of a very short programming exercise, not to solve a stupid “gotcha” problem, but to make sure you can actually write a program. (You’d be surprised how many self-proclaimed senior developers can’t write a decent program.) There will be 5-6 technical questions that a mid-to-senior level developer should be able to answer with ease. If you are a Zend Certified Engineer these questions will be no-brainers.

After you pass that we’ll fly you out to to Scottsdale AZ to interview for personality fit. Once you pass that we hire you and you get a better job than you have now.

Send me two copies of your resume: one in plain text in the body of the email so I can read it directly, and attach a Word or PDF copy for my HR guy.

That is all.

UPDATE: Fixed the email address.

Complex Systems and Normal Accidents

One of my favourite sections of the book was Harford’s discussion of accidents. Most of the problems Harford examines in the book are complex and “loosely coupled”, which allows experimentation with failure. But what if the system is tightly coupled, meaning that failures threaten the survival of the entire system? This concept reminded me of work by Robert May, which undermined the belief that increased network complexity led to stability.

The concept of “normal accidents”, taken from a book of that title by Charles Perrow, is compelling. If a system is complex, things will go wrong. Safety measures that increase complexity can increase the potential for problems. As such, the question changes from “how do we stop accidents” to how do we mitigate their damage when they inevitably occur? This takes us to the concept of decoupling. When applied to the financial system, can financial institutions be decoupled from the broader system so that we can let them fail?

(Emphasis mine.) via Harford’s Adapt: Why Success Always Starts with Failure.

Interview Tip: Avoid Mentioning PHP Frameworks

If the job description does not mention “Framework X,” you should probably avoid answering that you use “Framework X” to solve the problem presented to you by the interviewer. If I ask you to perform a simple task, such as parsing a string in a well-known format, saying “Framework X does that for me” is likely to be seen as a negative.

You should be able to do the simple things in PHP itself (e.g. parsing strings). As interviewers, we generally care about your proficiency with the language, not with how much you like the framework of your individual choosing.

Saying that you use a feature of “Framework X” for simple things is a negative. It sounds like you’re dependent on that framework for basic tasks. That means we (the employers) will need to train you how to do it without that framework, and that’s a hassle for us.

One caveat here is that if the employer has already specified that they use “Framework X” then they probably do want to see that you’re familiar with it. Alternatively, if you are going to be the only person on the team, you’re also probably fine. But in collaborative, team environments, it is unlikely that the employer is already using the framework you, individually, prefer.

phpDocumentor2 === DocBlox

This is great news. Congratulations to both projects!

Announcing phpDocumentor 2 – the merging of the old (phpDocumentor) and the new (DocBlox).

With the first alpha release of phpDocumentor (2.0.0a1), the new “Responsive” default template sports a new page layout, along with the useful layout improvements that the original DocBlox templates provided (which remain available) over the old phpDocumentor templates (which will retire with old phpDocumentor).

via DocBlox is unmasked … it is really phpDocumentor 2! : DocBlox.

On Preferring Spaces Over Tabs in PHP

The best lack all conviction, while the worst are full of passionate intensity. — “The Second Coming”, William Butler Yeats

Keep the above in mind when considering either side of the debate. 😉

tl;dr

Herein I assert and discuss the following:

  • Using spaces has subtle advantages over using tabs in collaborative environments.

  • The “tabs reduce file size” argument is factually true, but is a case of optimizing on the wrong resource.

  • The “tabs allow each developer to set his own indent widths” argument sounds good in theory but leads to problems in practice regarding line length recognition and inter-line alignment.

Introduction

In the PHP world, there are effectively two competing indenting practices: “4-spaces” and “tab.” (There are some in the 2-space camp as well but they are very few.)

I want to point out a couple things about why spaces might be considered preferable in a collaborative environment when style is important on a PHP project. And yes, it turns out this dicussion does matter.

I used to use tabs, and slowly migrated over to spaces. Over the course of several years, I have found there is a slight but useful advantage to using spaces for indentation when working with other developers, and I want to discuss that one advantage in this essay.

Note that I am not asserting an overwhemling, absolutely obvious, infallible moral rule that clearly favors spaces over tabs as the One True Path. It is merely a noticeable improvement regarding more sophisticated rules of style.

Do I expect this essay to change anybody’s mind on using tabs? No; but, I do hope it will give some food for thought.

Regarding Tabs

When making an argument, it is important to state the alternative viewpoint in a way so that people who hold that viewpoint actually agree with it.

What are the reasons for preferring a tab indent? As far as I can tell, they are:

  • The tab is a single character, so files are smaller.

  • Using a tab character allows each developer to change the level of indent
    that he sees, without actually modifying the on-disk file.

If there are other reasons I have missed, please let me know.

File Size

In general, I assert that the “file size” argument is a case of “optimizing on the wrong resource.”

By way of example, let’s take one file from a real project that uses 4-space indenting, Zend_Db_Abstract, and use wc -c to count the number of bytes in the file.

$ wc -c Abstract.php
40953 Abstract.php

Now, let’s convert each 4-space indent to a tab.

$ unexpand -t 4 Abstract.php > Abstract-tabs.php
$ wc -c Abstract-tabs.php
34632 Abstract-tabs.php

We save 6K of space on a 40K file, or roughly 15%, by using a tab character for indents instead of a 4-space indent.

Now, to get an idea of how that compares to another way to reduce size, let’s remove all the comments from the original 4-space file and see what that does. We’ll use a tool I found after two minutes of Googling (you may need to change the hashbang line of remccoms3.sed to point to your sed):

$ wget http://sed.sourceforge.net/grabbag/scripts/remccoms3.sed
$ chmod +x remccoms3.sed
$ ./remccoms3.sed Abstract.php > Abstract-no-comments.php
$ wc -c Abstract-no-comments.php
21022 Abstract-no-comments.php

That’s about a 50% reduction. If disk storage is really a concern, we’d be much better off to remove comments than to convert spaces to tabs. Of course, we could do both.

This example makes me believe that the “file size” argument, while factually correct, is a case of “optimizing on the wrong resource.” That is, the argument gives strong consideration to a low-value item. Disk space is pretty cheap, after all.

A followup argument about this is usually, “Even so, it’s less for the PHP interpreter to deal with. Fewer characters means faster code.” Well, not exactly. Whitespace is tokenized, so the parser sees it all the same.

Developer Tab Stop Preferences

This, to me, seems to be the primary argument for preferring tabs over spaces for indenting. Essentially, the idea is to allow each individual developer on a project to make the code look the way that individual developer prefers.

This is a non-trivial argument. It’s very appealing for the individual developers to be able to work on a project where Developer A sees a tab stop every 4 characters, and Developer B sees a tab stop every 2 or 8 or whatever characters, without changing the actual bytes on disk.

I have two arguments against this; they seem to be minor, until we examine them in practice:

  • It becomes difficult to recognize line-length violations with over-wide tab stop settings.

  • Under sophisticated style guides, inter-line alignment for readability becomes inconsistent between developers using different tab stops.

These arguments require a little exposition.

Line Length Recognition

Because of limitations of this blog, let’s say that our coding style guide has a line length limit of 40 characters. (I know, that’s half or less of what it should be, but it serves as an easy illustration.)

The following code, with 4-character tab stops, shows what that line length limit looks like:

         1         2         3         4
1234567890123456789012345678901234567890
function funcFoo()
{
    $varname = '12' . funcBar() . '34';
}

It’s clearly within the line length limit. But it looks like this under an 8-character tab stop:

         1         2         3         4
1234567890123456789012345678901234567890123
function funcFoo()
{
        $varname = '12' . funcBar() . '34';
}

A developer who sees this code under 8-character stops will think the line is past the limit, and attempt to reformat it in some way. After that reformatting, the developer working with 4-character tab stops will think the line is too short, and reformat it back to being longer. This is not particularly productive.

Some will say this just shows that line length limits are dumb. I disagree.

Inter-Line Alignment

By “inter-line alignment” I mean the practice where, if we have several lines of code that are similar, we align the corresponding parts of each line in columns. To be clear, it’s not that unaligned code is impossible to read; it’s just noticeably easier to read when it’s aligned.

Typically, inter-line alignment is applied to variable assignment. For example, the following unaligned code …

$foo = 'bar';
$bazdib = 'gir';
$zim = 'irk';

… is easier to scan in columns aligned on the = sign:

$foo    = 'bar';
$bazdib = 'gir';
$zim    = 'irk';

We can see clearly what the variables are in the one column, and what the assigned values are in the next column.

Alternatively, we may need to break an over-long line across several lines, and make it glaringly obvious during even a cursory scan that it’s all one statement.

Now, let’s say we have a bit of code that should be aligned across two or more lines, whether for readability or to adhere to a line length limit. We begin with this contrived example using 4-space indents (the spaces are indicated by • characters):

function funcName()
{
••••$varname = '1234' . aVeryLongFunctionName() . 'foo' . otherFunction();
}

Under a style guide where we align on = to keep within a line length limit, we can do so regardless of tab stops:

function funcName()
{
••••$varname = '1234' . aVeryLongFunctionName()
•••••••••••• . 'foo' . otherFunction();
}

Under a guide where we use tabs, and Developer A uses 4-character tab stops, we need to push the alignment out to the tab stops to line things up (tabs are indicated by → characters):

function funcName()
{
→   $varname→   = '1234' . aVeryLongFunctionName()
→   →   →   →   . 'foo' . otherFunction();
}

However, if a Developer B uses an 8-character tab stop, the same code looks like this on Developer B’s terminal:

function funcName()
{
→       $varname→       = '1234' . aVeryLongFunctionName()
→       →       →       →       . 'foo' . otherFunction();
}

The second example has the same tabbing as in the first example, but the alignment looks broken under 8-character tab stops. Developers who prefer the 8-character stop are likely to try to reformat that code to make it look right on their terminal. That, in turn, will make it look broken for those developers who prefer a 4-character stop.

Thus, the argument that “each developer can set tab stops wherever he likes” is fine in theory, but is flawed in practice.

The first response to alignment arguments is generally: “Use tabs for indenting and spaces for alignment.” Let’s try that.

First, a 4-character tab stop indent, followed by spaces for alignment:

function funcName()
{
→   $varname = '1234' . aVeryLongFunctionName()
→   •••••••• . 'foo' . otherFunction();
}

Now, an 8-character tab stop indent, followed by spaces for alignment:

function funcName()
{
→       $varname = '1234' . aVeryLongFunctionName()
→       •••••••• . 'foo' . otherFunction();
}

That looks OK, right? Sure … until a developer, through habit (and we are creatures of habit) hits the tab key for alignment when he should have used spaces. They are both invisible, so the developer won’t notice on his own terminal — it will only be noticed by developers with other tab stop preferences. It is the same problem as before: misalignment under the different tab stop preferences of different developers.

The general response at this point is to modify the tab-oriented style guide to disallow that kind of inter-line alignment. I suppose that is reasonable if we are committed to using tabs, but I find code of that sort to be less readable overall.

Solution: Use Spaces Instead

The solution to these subtle and sophisticated issues, for me and for lots of other PHP developers, is to use spaces for indentation and alignment. All professional text editor software allows what are called “soft tabs” where pressing the tab key inserts a user-defined number of spaces. When using spaces for indentation and alignment, all code looks the same everywhere, and does not mess up alignment under different tab stop preferences of different developers.

Conclusion

I realize this is a point of religious fervor among developers. Even though I have a preference for spaces, I am not a spaces zealot. This post is not evangelism; it is a dissection of the subtle and long-term issues related to tabs-vs-spaces discovered only after years of professional collaboration.

Please feel free to leave comments, criticism, etc. Because this is such a touchy subject, please be especially careful to be civil and maintain a respectful tone in the comments. If you have a very long comment, please consider pinging/tracking this post with a blog entry of your own, instead of commenting directly. I reserve the right to do as I wish with uncivil commentary.

Thanks for reading, all!

Differences in Packaging Approaches: Aura, Symfony2, and ZF2

Looking from outside both Symfony2 and ZF2 is full of standalone components. But the reality is not the same. Though Symfony2 components are split into each components in github, you cannot give a pull request to that component. The tests for all the components still resides in the core. The same will be applying to ZF2 too. I wrote my concern on the topic in mailing list of Symony2, if you are interested you can read on it here.

Let’s leave the contributions or pull requests, if I / you are trying to integrate Symfony form component to your project or library, we want to bring the tests some how make the necessary changes to the core if I want to make use of Event Dispatcher / Signal or another like Aura or Zend. Try to make how you can render in your view if I am using Aura View or Zend or even in phly_mustache.

So let me tell you the design principle to make them as standalone have some failure. Coming back to Aura, as a small contributor I can see Paul M Jones right decision to make the component library has more to speak. The good thing is Aura has all the tests in one place for the component. For eg: consider Aura Router the routing component. The source lies in src folder , the tests in tests folder.

My biases in posting this should be clear. 😉 Via Is there a design flaw for the Components or Packages made by Symfony2 and ZF2 | harikt.com.