Can’t have multiple projects open at once

In Komodo Edit 5.x, your “Projects” pane can have a bunch of projects listed in it, which is very useful – I tend to have a couple of projects open at once, so I can check in one project how I did something (or how an API works), and work in another project. In IDE 6.x however, only one project is open at once, so I’d need to actually open the reference project, open the file, check it out, then switch back to my working project. Tedious.

Worse, projects now keep track of what tabs you have open – so if I open one file file for reference, then switch to another project, I lose all my open tabs.

Definitely decreased functionality. For this reason alone, I’d stay with Edit 5.x.

“Project” pane and “Code” pane are both in the left pane

I can either look at the files in my project or see the Code pane. I need both. I figured “easy, I’ll just switch the Code pane to the right” but no dice. There’s no option for that. No setting anywhere. I looked throughout the install directory to boot, to see if there was something I could hack to get it usable, but nothing. I can’t even have them BOTH open in the left pane (splitting the pane into two vertical sections).

Again, pretty much unusable.

I really want to like IDE 6.x, but these are pretty much showstoppers. Thankfully 6.x is going to be in beta for “months more”, so with any luck things like this will get fixed, but I’m surprised they’re here in the first place. Am I the only developer in the world who works from multiple projects at once and wants to see both files and code layout at the same time?

“Great,” I thought. “Time to figure out what’s broken.”

See, one of the strengths of Kohana is that the maintainers are totally willing to break backwards compatibility in order to refactor something a better way. However, one of the weaknesses of Kohana is that the maintainers sneak in and break shit when they update.

It’s entirely the same thing, depending on how you look at it. Thankfully, the devs rarely change anything sufficiently large enough to warrant more than a couple hours of bringing things up-to-code, and when I’m done that task, I generally end up with happier, nicer-looking code as a result. So I can’t be too upset.

To boot, there’s usually some sweet ups along the way. New functionality, enhanced functionality, broken stuff fixed, that kind of thing. And while only a point-release, there’s some stuff in here this time that you very well may want to have.

Two Whole New Modules!

• The OAuth module lets you do neat things like integrate with Twitter without writing a lot of cruft code.
• The UnitTest module integrates PHPUnit directly into Kohana! This is so cool! I played around a few times before with trying to do this myself before giving up on it in favour of writing actual domain code. Now that someone more dedicated than myself has actually integrated it, who knows? I might even start writing test cases.

Better XSS Protection!

In all kinds of little places, characters are being escaped where they weren’t before, meaning that the XSS vulnerabilities that are in your project don’t creep in at the framework level.

A Whole Bunch Of little Fixes!

There seems to be generally better code documentation all over the place (example: the database config file), and a lot more flexibility opened up (example: final constructors removed all over the joint, the UTF8 file is now extensible). As well, there’s a bunch of little bugs fixed everywhere, meaning that all those little edge cases I haven’t run up against? I never will.

So What Broke?

Nothing!

Seriously, it just worked. I copied 3.0.7′s system directly over 3.0.6′s. Ditto for the auth and database modules. This is perhaps one of the worst ways you can do an upgrade because so many things can go wrong, but nothing did. I’m seriously impressed.

So there’s a couple of neat new things to play around with, a whole host of sweet little fixes – looks like a very solid update.

Kudos to the Kohana team!

Kohana 3 has a very neat structure that allows you to safely extend its base classes, adding functionality to classes as core as Kohana itself without ruining the interfaces other classes use to communicate with it.

The basic pattern is as follows:

abstract class Kohana extends Kohana_Core { }

class Kohana_Core {
    // Real functionality here
}

You may not recognize the brilliance inherent in this pattern if you don’t know a little something about Kohana – it autoloads classes in the following order:

# Application folder, then
# Module folders in the order defined in bootstrap.php, finally
# System folder

Which means, if you define your own Kohana class in your application/classes folder, then anytime anyone calls Kohana::debug(), they’ll be calling YOUR version of Kohana. Want to redefine debug() to output via FirePHP? Go nuts. Just make sure that your version of Kohana extends Kohana_Core.

But what if you’re developing a module, and you want people to be able extend ”your” version of Kohana? Well, you can follow the same pattern as the developers do:

abstract class Kohana extends Kohana_Modulename { }

abstract class Kohana_Modulename extends Kohana_Modulename_Core {}

class Kohana_Modulename_Core extends Kohana_Core {
    // Real functionality here
}

It looks a little convoluted, but bear with me. If people choose to define Kohana directly, they can, thus cutting off your module entirely. But if people choose to extend from your module, they can define Kohana_Modulename and place their functionality in there, remembering to extend Kohana_Modulename_Core from that class, and the whole chain remains. In fact, they can extend the chain further with this same pattern for their own Modulename.

Now, this doesn’t really help when two modules BOTH want to redefine Kohana and aren’t aware of each other, but that is probably always going to be a problem.

if (isset($modifier)) {
    // Do some things.

    // And some more things.

    // Still more
    // things
    // to be done here.

    // There's a whole lot of things here!

    // Last bunch of things
}
else {
    // Do totally different stuff
}

People. Comment your elses! I shouldn’t have to scroll up to read the if again just to figure out what a branch of logic does. This is a maintenance code nightmare, and simply adding a simple “// If validation has failed” will save all kinds of time and frustration.

Komodo Edit is awesome and you should all use it.

Seriously. I don’t know how much more I need to go on about this point, but the productivity benefits of a good IDE are astounding, and if you’re still using Notepad or gedit or the like like, then you are Doing It Wrong.

If I had to recommend a good IDE, I’d recommend Komodo Edit. I have before. Hell, I’m still their go-to quote, a fact that I find puzzling, yet rewarding.

Anyway. The guys at Activestate switched to using the Mozilla codebase a while ago, which means that anyone who can write a Firefox extension can (in theory) write a Komodo extension. And so they have! And I have found three that I have fallen absolutely in love with.

They are:

TODO Helper

The TODO Helper plugin is great if you leave all kinds of little “TODO:”s scattered through your code as mental bookmarks. This plug-in can quickly search your entire project for all TODOs listed and display them in the bottom panel.

It’s a little frustrating when the framework you’re using leaves TODOs in their releases, but it’s not hard to take those suckers out anyway.

kJSLint

A long while ago, I blogged about how to integrate jslint into Komodo Edit, but I guess that’s not really strictly necessary these days. Since there’s a plugin that integrates jslint into a menu command.

Sure, you lose out somewhat on the ability to control exactly what version of jslint you use, but the version included is rather up-to-date, and saves you the trouble of having to install an interpreter just to run it. A definite win.

(Also, the “Crockford says no.” message it spits out when you fail validation makes me smile every time.)

Source Tree

Though not as slick as Komodo IDE’s code browser, at least the Source Tree plugin is free and does what it says on the tin. Having the entirety of the file’s functions and classes available and easy to navigate is very handy. Shame this isn’t in the free version of Edit to start, but they’ve got to have some features to differentiate the two enough to encourage people to buy the “pro” edition.

And in Conclusion

Komodo Edit. It’s good. Komodo Edit with Plugins. Even better.

Now get coding.

But there are those of us who fight! Who rage against the dying of the light! Those who are more than happy to share our solutions to cleaning up ugly code, in the hopes that up-and-coming programmers will notice and apply said solutions. This… is one such solution.

Take, for example, nested conditions. They look like:

if (thing) {
    [CHUNK A]
    if (thing) {
        [CHUNK B]
        if (thing) {
            [CHUNK C]
        }
    }
}

It’s not THAT ugly, but try extending that out into five or more chunks, or if you’ve already indented a couple of times, you will notice just how ugly this looks. Since each chunk is only executed based on the result of a boolean test (the if statements), and each chunk is directly dependant on the previous chunk (and oughn’t be run if the previous chunk fails), we can take advantage of short-circuit operators and rewrite this section of code to be much cleaner.

Instead, rewrite each chunk into its own function, have that function return a boolean, and you can rewrite the original code like:

$success = do_chunk_a();
$success = $success && do_chunk_b();
$success = $success && do_chunk_c();

This is a huge win in terms of readability, and therefore in terms of maintainability. Especially so if you name your new functions descriptively, like “send_invoice()” or “update_client_list()”. It’s far easier to look at the descriptive name of the functions instead of having to read through the entirety of each chunk, just to find out what the code is supposed to do.

1) Namespaces

Adding namespaces solves, in a stroke, a great many conflicts that developers tend to run into with PHP. For example, if I write a database layer class called db and YOU write a database layer called db, and I try to include another library that you’ve written that references your database layer, I’m boned. Since they’re both declared globally, this attempt at code re-use fails.

However, if I write a database layer and I decide to put it in the “danhulton” namespace, and you put yours in the “anotherlibrary” namespace, we’re fine. I refer to “danhulton\db” and you refer to “anotherlibrary\db” and all is right in the world.

Sadly, the namespace delimiter they’ve chosen is the backslash, which to my eyes just looks ODD, and also can run you into issues if you ever have to put your namespace in a string (with backslash being the escape character). Still, this is a net win for writing shareable PHP code.

2) Anonymous Functions

I got into the habit of using anonymous functions liberally in javascript, and have come to sorely miss them in PHP. Sure, you can emulate them with create_function(), but the syntax is awkward and the resource cost prohibitive. As of PHP 5.3, we’ll be able do do something a little like this:

$escaped = array_map(function($value) {
    return "'" . $value . "'";
}, array('sql', 'parameters', 'that', 'need', 'escaping'));

I’m very much looking forward to the cleaner code this will allow me to produce.

3) Ternary (?:) Operator

The ternary operator already exists in PHP, and I use it frequently. It allows you to do something like this:

$colour = ($balance > 0) ? 'green' : 'red';

Or, if you need to ensure a value is set before using it, you can write:

$entries = isset($entries) ? $entries : array();

In PHP 5.3, you’ll be able to simply write:

$entries = $entries ?: array();

Which means you can also write:

foreach ($entries ?: array() as $entry) {
    // some stuff
}

This change is excellent because, again, it leads to cleaner code.

4) Native MySQL library driver

This should be a huge win for many applications which value efficiency. (Although, isn’t that all of them?) The MySQL native driver is a full replacement for the currently-used driver written my MySQL AB. It is more efficient in terms of memory usage (storing all rows only once instead of twice), and should be just as processor-friendly, if not more. Further, there are a host of performance statistics calls that should ensure that performance debugging is much easier, and they include a function I wish had been there from the beginning: mysqli_fetch_all(). No more having to write a big while() loop with mysql_fetch_assoc(), this baby will take care of you in one line.

Now, since I’ve switched to the Kohana framework, my database functions are a lot friendlier already, so the latter function won’t specifically change how I code. But the decreased memory costs, especially for queries that return many rows, will be fantastic.

Conclusion

PHP 5.3 is going to be an excellent addition to the language, one I can’t wait for. I expect a fair amount of grumbling as we get adjusted to all the new features, and I’m rather curious to see what Kohana and other frameworks decide to do with regard to support (ideally for Kohana, IMHO, is keep KO 2.3 compatable with PHP 5.2.9, but require PHP 5.3 for KO 2.4 and 3.0). However, in the long run, we’ll have the ability to write cleaner, clearer, and less code, and that will be a fantastic advantage.

At a basic level, the domain for the cookie is typically set to “www.yourdomain.com”. So if you have users redirected to “premium.yourdomain.com”, they lose their cookies because their domain no longer matches. If you set the domain for your cookies to “.yourdomain.com” however, cookies set in one subdomain will match and carry over to other subdomains.

You can set this via php.ini, in your .htaccess files, through an ini_set() call, or even through a session_set_cookie_params() call. However, if you’re using Kohana (as I am), what you actually need to do is to copy system/config/cookie.php to application/config/cookie.php and modify the domain parameter to match the following:

$config['domain'] = substr($_SERVER['SERVER_NAME'],
                           strpos($_SERVER['SERVER_NAME'], '.'),
                           100);

This way, no matter what server name you’re using (development or live), the right cookie domain is set.

One final thing to keep in mind when you’ve implemented this little solution – don’t forget to clear your cookies! I spent a further twenty minutes thinking I’d missed something code-wise because Firefox still had a better-qualified cookie left over from before and was relying on that instead of my sparklin’ new “.yourdomain.com” cookie.

FireStick is a (relatively) simple to configure library that enables easy and low-overhead performance logging in CodeIgniter.

Performance measuring and logging is an important part of application maintenance and improvement. FireStick makes it easy to record page render times, MySQL call times, and other related information that you can use to track down performance issues.

FireStick relies on CodeIgniter’s built-in performance and benchmarking capabilities and a post-system hook. When the hook is called, FireStick logs all this information to the database for review at a later date.

Logs are split up into multiple tables based on date, with each new day’s table created automatically on the first request of each new day. All logs are added using INSERT DELAYED so as to minimize impact on the database server.

Main project page: http://code.google.com/p/firestick/
Project source: http://firestick.googlecode.com/files/firestick-1.0.zip
Installation instructions: http://code.google.com/p/firestick/wiki/Installation

I’ve been reading High Performance MySQL lately, and the very first section of the book is on profiling, why it’s a good idea, and how to go about doing it. Since I’ve deployed ComingUp out in the wild, I figured I should be profiling, too.

So I put together this little add-on library for CodeIgniter that takes the basics presented in the text and adapts them to CodeIgniter’s already well-rounded benchmark system. CodeIgniter already has total script execution time measured, total script memory consumption, and a full list of all DB calls and the amount of time they took. I just collated all of that and put it into a sensible DB logging system.

The whole deal is open source, too. GPL v3. Any CodeIgniter developer anywhere can feel free to use this, and I’d be happy if they did.

If you are using it, and you encounter any bugs or want to provide feedback, please leave a comment in the FireStick thread on the CodeIgniter forums, and I’ll be happy to address it.

As an example of just how bad things can get, here’s an example of a terrible bug report:

I make an order and click Next but get told error about not supporting billing.

As a developer looking to test that bug, I would have absolutely no idea how to start. I’ve likely submitted dozens of orders already and none of them have failed, least of all with some ambiguous error regarding the billing system. This is the kind of hair-pulling complaint I expect to see from my Mom when she’s having trouble buying from Amazon or setting up online banking.

Bug reports absolutely require 4 pieces of information:

1. Summary
2. Steps to reproduce
3. What you expected to see
4. What you actually saw

Let’s examine them individually.

1) Summary

Anyone scanning through long lists of bugs need to be able to instantly identify what a bug is about, so the summary has to be concise and uniquely identify the bug in question. Try to limit to 80 characters or less as a guideline. Avoid the urge to go into detail here – this can be included in the actual bug report itself.

Example: “Cannot submit Mastercard transactions with card expiration dates after 08/11″

2) Steps to reproduce

This is probably the most critical part of the bug report. A bug that can’t be found can’t be fixed, and a bug without listed repro steps is very hard to find. Provide these steps in an ordered list, ensuring that they are easy to follow and contain ALL information required to reproduce the bug, including setup steps that need to be taken to trigger it (like turning an option on or off).

Example:

1. Add Pink Cat Collar #3444 to cart.
2. Click check-out button.
3. Use development Mastercard (3557) with expiration date 08/12 to submit transaction.

3) What you expected to see

What you should have seen if there was no bug.

Example: “Order complete/receipt page.”

4) What you actually saw

What you saw due to the bug. If the program spits out any debug information, copy/paste it into your bug report. If it’s over 20 lines long, or if you need to include an entire HTML page or file, include it as an attachment.

Example: “PHP Error: ‘Line 42: Overflow in $cardChecksum’”

Optional – Further description

If you have more stuff to say about the bug than what’s listed above, don’t try to mash it into the fields above. Place it under the header “Additional Information” or similar. If you can find conditions the bug suspiciously doesn’t happen under, list them here. Don’t muddy the waters with ideas on how to fix the bug here, unless you’re absolutely certain you know what’s wrong. Your job is not to be the doctor and diagnose, but to be the patient and report symptoms.

Sloppy writing and conjecture isn’t encouraged anywhere in a bug report, but the one place you can get away with it is in the “Further description” field – provide as much information as you think is relevant. Developers would far prefer to have to read extra material than have to hunt you down to figure out just what your bug report meant.

Optional – Severity/Priority

The severity or priority of a bug indicates how damaging it is to the product. A properly set severity level is important, as often, bugs can either be fixed or not fixed based on a set schedule, and the severity level is used to identify which fixes make it in and which don’t. QA Testers are rarely the people who set severity levels of bugs, but I find they’re so often misunderstood that covering them here would probably help.

There are many schools of thought on how to properly categorize severity levels, but in the interests of brevity I’ll just cover one, a fairly common 5-level classification:

• Blocker – Blocks development or testing. Examples: Installer doesn’t work/application fails to launch.
• Critical – Loss of data, crashes, public exposure of private data. Examples: Renaming an account deletes it, listing the credit cards on your account lists all credit cards on all accounts.
• Major – Major loss of function, or function loss where no work-around exists. Examples: Layering function in a graphics editor doesn’t work, or unable to change font in a text editor.
• Minor – Minor loss of function, or function loss wher an easy work-around exists. Examples: “Close” button on tabs don’t work, but Menu->Close does, italics doesn’t work with little-used font.
• Trivial – Cosmetic problem that does not impede functionality. Examples: “Exit when finished” translates to “Please leave now” in Korean, where you sell five units a year, border around statistics doesn’t show up under certain browsers.

Keep in mind that severity doesn’t necessarily equate to priority, and these are typically separate fields in many bug tracking systems. A Critical bug that affects only one customer worth $200/month should definately have a lower priority than a Major bug that affects multiple customers worth multiple thousands.

Summary

The aim of the bug report is to make the failure you encountered as instantly obvious to the developer assigned to fix it as it is to you. Approach the whole thing scientifically. If I follow the same steps as you followed, I should get the same result, on which we can build (i.e. fix). You should aim to be specific and clear about what you’re reporting (never “it” or “the textbox”, use “the cursor” or “the address textbox” instead), concise in your summary and repro steps, and accurate.

With only a little more effort and attention paid to including the right information, you can turn a rushed, bad bug report into a thoughtful, good bug report. Your developers will thank you, your managers will thank you, heck, Amnesty International will probably thank you. Okay, well maybe not, but still, it’s a good idea.