I’ve recently switched from using Netbeans as my PHP dev tool of choice to Sublime Text 2. Features-wise, I think Netbeans is great. During the years I used it, I never felt that there was a feature I needed that was missing at the time. But, like all the current crop of Java-based desktop IDEs, it’s so damn ugly [1] and slow [2] that I’ve had enough. I program because it’s something that I love doing, and anything that gets in the way of that … I’ve no time for any more. So when a work colleague introduced me to Sublime Text 2, I was in the mood to give it a go, and 3 months on, I haven’t opened Netbeans once.

I’ll be the first to say that Sublime Text 2 isn’t for everyone.

  • It’s a beta product, which means there are some rough edges (mostly in the plugin API I feel), but it’s more than stable enough for production use. It has crashed a couple of times, which might put some people off, but I don’t recall losing any work as a result. File management in the project pane still needs work. The regular dev builds occasionally break things.
  • It isn’t a full-blown IDE; it’s more like the spiritual successor to TextMate, an editor that I never personally cared for. In particular, it doesn’t support interactive debuggers, which means no Xdebug support, and there’s currently no obvious way for a plugin to add that functionality in [3].
  • Auto-completion isn’t anything like what you’re used to. The built-in auto-completion is based on a mix of static knowledge of languages and fuzzy matching against what you’ve recently typed. There’s no obvious intelligence about the code you’re working on, nor the parameters for any method or function. These are two things that many people will deeply miss. [4]
  • It isn’t free, but you can evaluate it for free with no time limit. If you decide to buy, it’s substantially cheaper than both PhpStorm and Zend Studio, and there’s no annual subscription element to the licensing. You’re buying a license to support and encourage an independent developer, and to show your appreciation for a very nice piece of software.
  • It’s a closed-source product. You can’t fix it yourself if it breaks, and no-one can pick up the reigns if it gets abandoned. There seems to be just one guy behind it, and if anything happened to him, that’d probably be the end of the product. That said, most of the alternatives are also closed-source too.

Given all of that, why have I switched?

  1. Sublime Text 2 is very very fast. Sublime Text 2 itself opens instantly. Files open instantly (provided they’re not 100 megabyte test data files). In fact, everything happens instantly – even inside a virtual machine running on a 3 year old laptop. There are no pauses for anything to be indexed, and I’ve never seen CPU usage spike – important for us untethered users and our suffering laptop batteries [5]. And if a plugin slows things down at all, Sublime Text 2 tells you which one is the culprit so that you can go and disable it. I’d compare the importance of the speed difference to switching from a hard disk to an SSD. You don’t realise how much you’re waiting for your slow Java-based IDE until you use something that’s properly fast.
  2. It renders fonts properly – Droid Sans Mono and Ubuntu Mono in particular both look gorgeous – and even after a long day of use, my eyes don’t feel like they’ve been scratched on the inside by sharpened kitty claws all day long [6]. True story: one of my colleagues came over to ask what I was using, because he thought it looked so nice from a distance. When was the last time anyone ever thought that about a desktop Java app?
  3. All of the searching is based on an extremely powerful fuzzy matching approach. Netbeans supports regexes, which can be very handy, but most of the time when I’m looking for something, a regex is overkill but a simple string search isn’t powerful enough. If I’ve got both a class called ‘IpcProcess’ and ‘IpcProcessID’, in Sublime Text 2 I can find the ‘IpcProcessID’ class by searching for ‘ipi’; I just have to type the shortest set of characters that uniquely matches what I’m looking for. It’s much quicker than writing (or running) a regex, and soon becomes second nature.
  4. There’s a “goto anything” search panel which is lightning quick. Combined with the fuzzy matching approach, I find this a godsend for working on multiple large code bases, where there may be different classes with the same base filename, or duplicate installs of a class in vendor folders, or where I’ve got both trunk and branches checked out for the same project. It’s a killer feature, and one that has changed my workflow for the better, especially combined with my next reason. The panel’s also like using Google Instant – you get results as you type, giving you the instant feedback you need to refine your fuzzy search. (There is also a “goto symbol” search panel, and a “command palette” which allows you to search through the available editor commands to execute).
  5. Everything can be done from the keyboard. Everything can be done from the mouse too, but I found that doing everything from the keyboard is both faster and doesn’t break the flow of what I’m working on. This is something I didn’t appreciate until after I’d switched, but it’s a fantastic help to me when I’ve got another developer sat next to me and we’re looking at (or for) something together. Together with the fuzzy matching, it’s like doing software archaeology with a JCB digger instead of a trowel.
  6. It does a great job of auto-detecting whether a file uses spaces or tabs for indentation, and how big the tab stop is. There are days when it seems like no two files I open are consistent in how the code is indented, and it’s rare for anyone to have tagged on a modeline to give any hints. With Netbeans, which has a rigid config-based approach to indentation, I end up playing code-formatting table tennis with the original author of the file, as we always seem to have different indentation settings. Sublime Text 2 works out what the existing indentation approach is, and just auto-configures itself to match. It’s a great time saver [7].
  7. It strips trailing spaces from the ends of lines when I save my files. This has been broken in Netbeans for years! It’s a small thing, I know, but it really annoys the crap out of me that Netbeans doesn’t get this right. As a bonus, in Sublime Text 2 trailing spaces actually get their own setting in color schemes, so you can see exactly where they are. In Netbeans, they’re bloody invisible :(
  8. There’s a healthy ecosystem of plugins for it – over 200 plugins and counting – thanks to Will Bond’s Package Control package manager. Will is doing a great job of making sure that each plugin is tightly focused on sorting one problem only, to keep Sublime Text 2 as flexible and adaptable as possible – something to keep in mind if you start writing plugins yourself.
  9. Creating new plugins is very easy. It took me just one evening to add and release the initial PHPUnit plugin, and that included the time it took to learn both Python and the plugin API from scratch. To make an update to your plugin, simply push your changes to your master branch on GitHub. It’s as close to frictionless as you can get.
  10. I can own the tool, and set it up to suit my approach to programming. Because extending the editor is so effortless, I can automate anything that I want, to suit exactly how I want it done. I can create snippets, intelligent macros, and full-blown plugins to suit, and I can make them as and when some new need occurs – even one-off tasks. In this, it reminds me most of JED, which was my text editor of choice back in the 90′s for exactly the same reason. It’s the same reason folks love Vim. (Btw, Sublime Text 2 has a Vim mode. I haven’t tried it, so I can’t vouch for whether it’s good enough to tempt Vim users over or not).

Like Netbeans, Sublime Text 2 works on OS X, Linux and Windows [8], so I can use it everywhere I used to use Netbeans. I reckon it occupies a sweet spot that makes it very well suited to scripting languages and C/C++ development, albeit minus support for interactive debuggers.

At work, some of us have taken to it, and some of us haven’t. I’m happy to recommend it to anyone who’s looking for a change. You can take advantage of the open-ended free evaluation period, and see if it suits you or not. It’s working for me so far, and I probably spend more time using it than any other app on any of my computers.

If you do like Sublime Text 2, I’d love for you to leave a comment below with your own reasons why.

Footnotes

  1. Dear Java, the 1990′s called and asked for their crappy non-aliased font renderer back. I think Windows 3.11 is missing it terribly.
  2. There was a similar parallel around 20 years. At the time, Emacs was by far the most fully-featured editor, but everyone I know chose vi because of how slow and bloaty Emacs was at the time. It was so bad, we used to say that Emacs stood for “Eight megs and constantly swapping” (this was back in the days of 640K of RAM).
  3. The lack of debugger support is, for me, the one feature that I miss every single day.
  4. There is a plugin that tries to bring Komodo’s auto-completion to Sublime Text 2, but it stopped working for me before Christmas sadly.
  5. It’s like when you switch from Firefox to Chrome for the first time … your laptop just gives a sigh of relief, and you don’t have to worry quite so much about how far away you are from the next convenient wall socket to recharge from. I can easily imagine running this on a netbook, or a laptop with very aggressive CPU throttling in place – both places where a Java-based IDE would struggle.
  6. I’m highly visual, and find it really tiring to spend 10-12 hours a day in front of poorly-rendered fonts.
  7. Now, if only everyone just did the right thing in the first place and used spaces instead of tab characters, we wouldn’t need functionality like this … :)
  8. The keybindings are different from one platform to another, and because Python isn’t a platform-agnostic language, some plugins may not work properly on Windows at first. But most plugin authors are happy to accept pull requests with portability fixes.

50 comments »

PHPUnit Plugin For Sublime Text 2

Posted by Stuart Herbert on February 4th, 2012 in Toolbox.

Sublime Text 2 is a new cross-platform text editor that I’ve recently switched to. It’s still in public beta, but already offers better performance (and battery life!) and a better look (fonts that render properly!) than Java-based IDEs such as Netbeans.

One thing it didn’t have was support for PHPUnit, so I’ve made a plugin. It’s available to install via Package Control.

You Need A phpunit.xml or phpunit.xml.dist File

To use this plugin, your project needs to contain either a phpunit.xml or a phpunit.xml.dist file. This file contains all the configuration that needs to be passed to PHPUnit. The plugin searches upwards from your code, and will favour a phpunit.xml file over a phpunit.xml.dist file if it finds both.

If you don’t have one, you need to go and create one now.

How To Use

If you have your code open in a Sublime Text 2 window, right-click inside the window to see what your options are:

  • Test This Class – click this option to run just the unit tests for this class.

    This option appears if the PHPUnit plugin can find your unit tests. It takes the name of your class, and uses the standard PSR-0 transformation to figure out what the name of your test file should be.

    For example, if your class is called ‘Phix_Project\CommandLineLib\CommandParser.php’, the PHPUnit plugin will search for a file ‘CommandLineParserTest.php’ that’s in a folder called ‘Phix_Project/CommandLineLib’.

  • Open Test Class – click this option to open up your tests in Sublime Text 2. If you already have the tests open, this will switch tabs to your tests.

    Again, this option only appears if the PHPUnit plugin can find your unit tests.

  • Run All Unit Tests – click this option to run all the unit tests for your code.

    This option just points PHPUnit at your phpunit.xml or phpunit.xml.dist file.

If you have your tests open in a Sublime Text 2 window, right-click inside the window to see what your options are:

  • Run These Tests – run these unit tests, using the phpunit.xml or phpunit.xml.dist file that the PHPUnit plugin has found.
  • Open Class Being Tested – open the class that these tests are for in Sublime Text 2. If you already have the class open, this will switch tags to your code.
  • Run All Unit Tests – click this option to run all the unit tests for your code.

If you’re someone who prefers keyboard over mouse, then you’ll probably want to run the PHPUnit plugin commands from Sublime Text 2′s Command Palette:

You get the same commands that appear on the right-click menu … the right commands will appear for the file that you’re currently editing, just as you’d expect.

Finally, you can also right-click on your phpunit.xml (or phpunit.xml.dist) file in the Project Sidebar, and run your unit tests using that specific config file.

Helpful Snippets

Like TextMate before it, Sublime Text 2 also has a handy snippets feature, where it can insert a pre-crafted block of text (or, in our case, PHP code) to speed up your coding. I’m collecting most PHP-related snippets in my Additional PHP Snippets plugin (hat-tip to Rob Allen for the inspiration for this), but the PHPUnit plugin includes a few PHPUnit-related snippets to help.

  • phpunit-testcase – will create a new test class for you to fill out.

    I find this handy mostly so that I don’t have to remember which class my test class has to extend :)

  • phpunit-test – will create a new test method for you to fill out.

To use any snippet, type its name and then press the <TAB> key. Sublime Text 2 will insert the snippet, and then you can use the <TAB> key to cycle through any placeholders that you need to edit.

If you find snippets useful, please don’t forget to check out my Additional PHP Snippets plugin too!

Feedback, Contributions Welcome

I’d love to hear how you get on with the plugin, and any ideas you might have for additional features. And pull requests via GitHub are most welcome too!

6 comments »

One of the questions I’ve been asked after yesterday’s blog post about Phix’s ContractLib is why not just use PHP’s built-in assert() function? I think it’s a great question, and the best way to answer it is to take a look at the key differences between two solutions.

Side By Side Comparison

Feature assert() ContractLib
Implementation PHP extension written in C (ships as standard part of PHP) PHP library written in PHP
Enable / disable execution Partial (there is an overhead when disabled, but it’s low) Partial (there is an overhead when disabled, but it’s higher)
Issues PHP4-style warning when tests fail Yes (configurable) No (throws a ContractFailedException instead)
Terminate PHP script when tests fail Yes (configurable) Only if the ContractFailedException is never caught
Quiet eval of test expression Yes (configurable) No (not required; test expressions are pure PHP code, not eval() strings)
Callback on failed test Yes (configurable) No (unwinds the stack instead by throwing ContractFailedException)
Throws Exception when tests fail No (but can emulate if you write your own assert() callback method) Yes (standard behaviour)
Tests are pure PHP code No – recommended way is to pass strings into assert() to be eval()’d Yes
Error report includes original value that failed the test No Yes
Support for per-test custom failure messages No Yes – are required to provide one
Support for Old Value storage and recall No (but can emulate by hand) Yes

The Differences Explained

The key difference is one of philosophy. assert() sits well with the PHP4 style of error reporting and handling, whereas ContractLib is firmly in favour of the OO world’s approach to reporting errors.

It’s a personal preference, but I think that PHP4-style errors have no place in code that has any desire to be robust. Exceptions aren’t perfect, don’t get me wrong, but their core property of unwinding the call stack in an orderly fashion makes writing robust code much easier. And they also carry a payload – information about what went wrong and why – which PHP’s assert() cannot provide to the same extent.

It’s much quicker to debug something when there’s a record of the value that failed the test. For that reason alone, I’d always prefer something like ContractLib over the built-in assert() approach.

But we can’t ignore the fact that these are tests that get shipped to, and executed in, the production environment. Unlike unit tests, adopting programming by contract will slow down your PHP code in production. The question is: by how much?

What About The Performance?

I’ve done some benchmarking between the two, using the five tests listed in the final example in yesterday’s blog post. It’s a real-world example of the kind of tests that I would look to add to code to improve robustness.

Here are the results I gathered, calling the tests 10,000 times in a tight loop. The tests were run from the command line, and the times do include PHP start-up / shutdown time and the time taken to parse each test file. I assumed a best-case scenario, where the tests would always pass.

Test Approach Time w/ Tests Disabled Time w/ Tests Enabled
Tests written using assert() 1.103s (100%) 5.989s (543%)
Tests written using ContractLib 3.055s (277%) 3.096s (281%)

When tests are disabled, using assert() is much cheaper than using ContractLib today. That’s to be expected, as assert() is written in C. I imagine that we could get close to the same performance if ContractLib was rewritten in C as a PHP extension.

But, when tests are enabled, assert() is much slower than ContractLib. Why? Because the recommended way to use assert() is to pass the test in as a string. PHP has to convert that string into bytecode to execute, and that conversion appears to be quite expensive.

Given the choice, I’d rather trade things running a little slower in production for having much faster tests when I’m writing code, and that’s why I created ContractLib. Plus I get much better information to understand why the test failed, and if I wanted to run the tests in production, I can handle their failures in a much saner way.

Final Words

In my experience, the time it takes to develop and ship code is normally more critical than how fast the code runs in production. Developer time has become a scarcer resource than CPU time.

Used intelligently, these kinds of tests in your code can help your team deliver quicker, because the code they are using and reusing is more robust first time around. Programming by contract is different to, and complements, unit testing because contract tests catch errors in using the code.

Whether you use ContractLib, assert(), or you create your own solution, you should really consider how much it is costing you when you don’t use these kinds of tests.

7 comments »

In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Phix is normally installed onto a development desktop or laptop; you would normally only need to install Phix on a server running CentOS if the server is a shared development server or a continuous integration server running something like Jenkins.

Follow these easy instructions to get phix installed on CentOS.

Using The One-Line Installer

The easiest way to get phix installed onto your CentOS server is to run the following command from a Terminal window:

curl -O http://phix-project.org/installers/centos-6.sh ; su -c 'bash centos-6.sh'

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), which is then run as the user “root”. The shell script:

  • Makes sure that you have a suitable version of PHP installed
  • Uses apt-get to install required dependencies
  • Uses the pecl command to install PHP extensions that we can’t get packaged for CentOS
  • Upgrades the PEAR installer to the latest version
  • Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

You can always find the latest installation instructions for phix on the Phix project’s website, including full instructions on how to do a manual install if you have trouble with our one-line installer.

Comments Off

In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.

We’ve created a development tool, called phix, to make it as easy as possible to create and maintain your own components written in PHP. Phix is normally installed onto a development desktop or laptop; you would normally only need to install Phix on a server running Debian if the server is a shared development server or a continuous integration server running something like Jenkins.

Follow these easy instructions to get phix installed on Debian.

Using The One-Line Installer

The easiest way to get phix installed onto your Debian server is to run the following command from a Terminal window:

curl -O http://phix-project.org/installers/debian-6.sh ; su -c 'bash debian-6.sh'

This command downloads a simple shell script (which you can find on GitHub if you want to read it before trying it!), which is then run as the user “root”. The shell script:

  • Makes sure that you have a suitable version of PHP installed
  • Uses apt-get to install required dependencies
  • Uses the pecl command to install PHP extensions that we can’t get packaged for Debian
  • Upgrades the PEAR installer to the latest version
  • Installs the package phix/phix4componentdev, plus dependencies, from the PEAR channel pear.phix-project.org

If all goes well, once everything has finished, run the following command and you’ll see that phix is now installed:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

Where To Find The Latest Installation Instructions

You can always find the latest installation instructions for phix on the Phix project’s website, including full instructions on how to do a manual install if you have trouble with our one-line installer.

2 comments »
Page 3 of 1712345...10...Last »