1

files.length

Which returned undefined. So if there is no length property present, an easy way to count the number of keys or properties of an object in ES5-compliant javascript environments like Node.js is to use the Object prototype directly:

1

Object.keys(files).length

A little more typing, but it is fast, efficient, and most importantly: already built-in.

Having a few well defined extension points force the developer to extend your library the right way instead of hacking your code.

The problem is that this kind of thinking is a slippery slope that kills the spirit of programming. It alienates the more pragmatic developers within communities. Telling other developers that you are going to force them to work with your code in some pre-determined “right way” is an incredibly arrogant statement to make. Instead of letting the codebase grow organically and be modified or extended at will, you handcuff developers and send them a different message. Allow me to re-phrase it using my own words:

I know the right way to use this code and I have thought of all the possible use cases. If you don’t agree, then you have to prove me wrong and wait until I either agree or figure out a better right way for you.

This is the real message developers hear when internal code is private scope or marked with the final keyword – a message that they have arbitrarily limited power and ability to make changes where they need to. But it doesn’t stop there.

When you take the position that all methods should be private unless proven otherwise, you plant a seed of fear in the developers that use your code. Fear that whenever they may have to veer off the beaten path to meet a project requirement they won’t be able to. Fear that they might miss deadlines waiting for the “right way”  to enable the functionality they need. Fear that they might have to modify or hack the actual file or class they need to change the behavior of to achieve the functionality they want within the project deadline because they are not able to extend it.

Using private scope removes the fun from programming and kills the hacking spirit by creating fear through the knowledge that you will not have the ability to make changes anywhere in the codebase you need to when you need to. You are no longer in control of your own code. You were forced to submit to a nanny state mentality by sacrificing your freedoms to modify the code for the promise of future stability and safety. That’s not a fun place to be when you’re on the receiving end, and it’s not a policy I would ever consider enforcing with my own code. I sincerely hope this line of thinking does not proliferate within the PHP community and infect other projects.

After playing with all three platforms, I settled on Appcelerator Titanium as my tool of choice for a few main reasons:

1. It produces native code, and is not just a simple html/css “web view” wrapper
2. It is javascript-based, which means I don’t have to learn a new language or try wrap my head around entirely new design paradigms
3. The application code is UI and event focused, which seems to make the most sense for native apps (“draw this button here”, “do this on click”, etc)

Starting Out

Starting your first project with Titanium is a bit rough. There are a ton of steps involved in setting up the Android development environment, and you’re pretty much on your own on how to do this from Appcelerator’s standpoint – the Android Developer website has instructions on how to do this, and it’s pretty much expected that you have gotten at least that far before beginning with Titanium. Xcode is easy to setup in comparison, but it’s a painfully long download at over 3GB.

Note that you’re going to have to have these environments setup regardless of the platform you choose, so it’s really not any discredit to the Titanium platform that they don’t have guides for this, although I think it would be wise for them to make some for the new-to-mobile-development people like me.

From a platform and code standpoint, the main thing that makes starting an Appcelerator project a bit tough is that there is little to no clear direction – the development process is literally wide open for you to do anything you want to do. This is good because it provides flexibility, but harder for newcomers because there is no defined answer for basic questions like “how do I organize my files?” or “where do I put configuration?”. It’s like a programming language without a framework. The answer is almost always “wherever you want to”. You try a few things, find what works for you, and then copy that structure and base skeleton files for all your future projects. What helped me most here is looking at a few existing open-source projects (like this one) and figuring out what they did.

The Development Experience

After you settle on an organization structure and get your app actually building and running an an emulator, the rest of the process is pretty easy and fairly smooth. The code syntax is calls to custom APIs with basic Javascript and JSON notation for options/settings, so most web developers will feel right at home, especially if they have ever had experience with javascript, jQuery or DOM scripting.

If you’re approaching Titanium from an MVC perspective, working with Titanium will be like spending most of your time in the “View” layer, and there really is no controller. Titanium and most native applications tend to be event-driven, and it works well with Javascript syntax and the way they have it setup. You’re essentially making direct calls within a script file, telling Z window or button to render at X,Y with given display properties.

Want a new blank window to open?

var myWin = Ti.UI.createWindow({
    title: 'New Window',
    url: 'mydir/new_window.js'
});
myWin.open();

Want a button that scrolls an image slideshow to the previous image on click?

// Create button object
var btnLeft = Ti.UI.createButton({
        left: 10,
        width: 30,
        height: 30,
        backgroundColor: '#333',
        image:'../images/icon_arrow_left.png'
    });
 
// Add button to current window
win.add(btnLeft);
 
// Scroll to previous image on click/touch
btnLeft.addEventListener('click', function(e) {
        if (activeViewIndex == 0) {
            return;
        }
        activeViewIndex--;
        scrollView.scrollToView(activeViewIndex);
    });

Most other basic operations are similarly easy and trivial to accomplish with Titanium. The code is fairly straight forward, is easy to understand, and does what it says. Furthermore, there really is no setup or boilerplate code that you have to write at all, which means once you get the hang of Titanium, you can create apps pretty quickly.

Cross-Platform Mobile Development

If your wish was to find a development platform that smooths out all the idiosyncrasies and differences between all the different mobile platforms and provide you with a single way to achieve the same things on all platforms, Titanium may not be for you.

Most of the provided Titanium UI APIs will work cross-platform, but they are tied to the native platform implementations of those features, so they are not guaranteed to look, work, or even act the same cross-platform. This leads to a lot of “try it and see” type development that consists of switching back and forth between code, re-building the project, and seeing how it works in the emulator on on your device. Although this type of blind development can be pretty frustrating at times, this approach makes sense and is actually a benefit to me as a sole developer. It means I don’t have to spend any time at all on styling, UI, images, or look and feel of the app – I just get the native look and feel out of the box. This is also good from an end-user standpoint, because users will have the same familiar look and feel with your app as they have with most others they use. Contrast this with development tools like PhoneGap where you use HTML/CSS, and you’re stuck creating your own whole look and feel with CSS (or using something like jQuery Mobile) for each app, and having the same look for all mobile platforms. That could be beneficial in some cases, but to an end user, suddenly having an iOS look on an Android app you launch is a bit odd when all the other apps you use have the Android UI.

The Difficult Pieces

The most difficult thing to deal with in Titanium is when a particular feature I want to use is well-supported on the iPhone, but causes immediate crashes in Android, with no warning from the compiler that the feature I am trying to use is not supported on the Android platform. This has lead to quite a bit more time-consuming “try it and see if it works” type development than I had originally bargained for — and the Android emulator isn’t exactly quick to re-compile and re-launch an app after making changes.

These developer headaches have not gone unheard through – Appcelerator just released Titanium Mobile SDK 1.5.0, which focused on full Android support. I upgraded and re-compiled a few of my apps to the new SDK, and most of the issues have been smoothed out. I have even been able to use code I had previously removed and have it work flawlessly now, so kudos to the Appcelerator Android team on their hard work. They are obviously committed to the platform and making it the best they can for developers that work on it.

The Finished Product

The app I made ended up being fairly simple – It’s an automotive app for Autoridge and the goal is to view vehicle photos by vehicle year/make/model, and view part numbers by category. It doubles as a simplistic vehicle database. The goal is to provide select part information for common replacement parts for your vehicle when you need to buy a part, but the part catalog is missing or your vehicle is not represented.

From a technical standpoint it’s pretty simple as well – It communicates with a JSON REST API and just displays the results on-screen in a native table view, with little special styling and no animations. The photo gallery was the most difficult and time-consuming piece of the whole app, and the 1.5 SDK release provided much better support for it on Android (even built-in swipe gestures for photo transitions!).

Summary

Overall, I have grown pretty fond of Appcelerator’s Titanium platform. It allows me to create iOS and Android apps quickly and without having to learn any new programming languages – a feat I had previously thought was out of my reach. The platform is in a noticeably beta-like status (currently at Mobile SDK v1.5.1 at the time of writing) with frequent updates and even some truly frustrating compatibility-breaking changes and inexplicably missing functionality. If you’re willing to stick with Titanium through the rough spots, you will be able to outpace native developers both in terms of line-for-line productivity and to-market speed for simple most apps, and will be able to compile them for both iOS and Android platforms as an added bonus.

Templating

Templating is perhaps the most compelling and creative use of closures that I have found, yet I haven’t seen any people or projects using closures this way. Closures are an excellent way to allow custom formatting for re-useable template widgets, like forms, datagrids, and lists. Re-useable forms and datagrids are pretty common in frameworks, because no one likes the monotony of creating a bunch of HTML forms or tables. They all seem to work great, until you have to change a few things in how they output the input fields or format cell data – then they can get a bit hairy and ugly to work with, and often require inheritance or use some obscure template syntax of their own with tokens that get string replaced and weak-to-no support for basic control structures like loops and if statements. Fabien Potencier published a proof-of-concept for individual field templates in Symfony2. This approach, while much more flexible than string-replaced field tokens, adds quite a bit of overhead because you now have to render one template per input field to produce a complete form. The same end result can now be easily achieved with the use of closures:

1
2
3
4
5
6
7
8
9
10

<?php
$table = new \Alloy\View\Generic\Datagrid('datagrid');
$table->data($this->posts)
    ->column('Post', function($item, $view) { return $item->title; })
    ->column('Status', function($item, $view) { return $item->status; })
    ->column('Date Published', function($item, $view) {
        return ($item->date_published) ? $view->dateFormat($item->date_published) : '(Unpublished)'; 
    });
echo $table;
?>

In this example, our generic “Datagrid” view accepts “$this->posts” as its data source input, and loops over it with a foreach internally. It then implicitly passes two arguments to any closure given that defines column output – “$item” – the current item in the posts collection we provided, and “$view” – the view object itself so helpers and other typical functions can be accessed.

The added benefits for using closures in this context are enormous. There is no additional (and limiting) pseudo-syntax to parse, and no additional item templates to render. The custom content is overridden in-line right where you want it to be (instead of being one-step removed in a separate template), and you can still use the native PHP code you know and love. The provided example is from Cont-xt CMS built using my own Alloy HMVC Framework.

Imagine how powerful and simple something like Zend_Navigation and the resulting navigation view helpers would become with support for closure templates. You would no longer have to rely on a deep hierarchy of nested configuration arrays, custom partial templates, or complex object inter-dependencies to generate page links with your own custom code.

Dynamic Code Extension

Dynamically extending a class and modifying the behavior of a code block with the use of closures is the foundation of a new php 5.3 framework called Lithium. Lithium’s specific approach uses closure chains inside function bodies to allow end-users to modify core functionality without modifying the core files themselves or having to use inheritance.

A more extreme example uses closures to enable dynamic run-time object creation. The idea is in an article titled PHP Object Oriented Programming Reinvented. The entire object and all its functionality is created with closures. The article is a good demonstration of the power of closures, but has little practical use.

One of the more practical (and perhaps controversial) uses I came up with is replacing string configuration values with closures if the return values needs to be dynamic. Here’s an example:

1
2
3
4
5
6
7

<?php
// Set in base config file
$cfg['path_uploads'] = function($cfg) { return "/uploads/" . $cfg['user_id'] . "/"; };
 
// Set dynamically by database value from logged-in user later in your application
$cfg['user_id'] = 74;
?>

This way, the ‘path_uploads’ config value will not have to be changed when the ‘user_id’ config value is. The closure will cause the config value to always be evaluated when called, and will always use the current ‘user_id’ value, so it will never be “out of date”. This, of course, requires you to have a standard way to retrieve config values from named keys, because closures can’t just be automatically converted to a string by themselves, and do have to be called a different way (like functions).

This is the only use that comes with a warning: beware how far down this road you travel. Dynamic code extension provides a lot of flexibility, but comes with the downside of code obfuscation and performance penalties. You are essentially adding class methods and modifying code behavior in places other than the code itself, which can lead to confusion when trying to trace code execution. Stack traces and development toolbars can help here, and using an opcode cache like APC can minimize the performance penalty.

Delayed Execution

Closures are a great tool to use anywhere you need to delay PHP code execution until a later time. A great example of this use is for a job queue system with multiple workers. Using closures, you can execute any arbitrary PHP code you need to without conforming to a specific structure — there is no need to create new classes or functions with set names determined by naming conventions, and no need to put “worker classes” in any specific place in the filesystem. Your worker task can be passed around and executed in parallel at will by the job queue.

Example: PHP Native Job Queue.

Caching

Using closures for caching is a bit of an extension of the delayed execution idea. Consider a cached block of code inside a view template using a closure:

1
2
3
4
5
6
7
8
9

<?php echo $this->cache(function($view) { ?>
    <?php
    // Expensive external HTTP request
    $blogRss = $view->helper('feedReader')->fetch('http://github.com/zendframework/zf2/commits/master.atom');
    $widget = new \MyApp\View\Generic\FeedList('feedlist');
    $widget->feedContent($blogRss, 'atom');
    return $widget;
    ?>
  <?php }, 'github_zf2_commits', 3600); ?>

Using a closure here offers two advantages over the typical ‘beginCache’, ‘…’, ‘endCache’ type calls that are more prevalent in pre-5.3 code. The first benefit is that through the use of a closure, our code block is contained in a variable before it is even executed. This allows us to use a cache backend like Memcache without having to use output buffering at all, saving us a tiny bit of overhead. The second big benefit is that executing our code chunk is entirely optional, without manually checking the cache first. This second benefit could also allow you to disable rendering of certain cached content completely if you need it, without any code changes in your view templates. Heavy-load or traffic spike scenarios come to mind as possible candidates for this functionality. Imagine being able to make a small configuration change to skip certain code blocks like $cache->disable(‘github_zf2_commits’) to serve a “lite” version of your site when you need all the server resources you can get.

Convenience

This may sound like a bit of a cop-out reason, but using closures in some cases really does make things a lot easier, and truly better. Consider the case where you have to use a one-off function to apply some sort of custom filtering logic to an array or collection of objects. With closures, you can just specify the logic in-place right where you need it instead of having to create a new function for the job in a separate location and having to figure out where to put it in your application, and then how to call it. It produces the same result in fewer lines of code with no side-effects (like having to make a global function).

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

// Collection of entities
$objCollection = array(
    new Entity(),
    new Entity(),
    new EntityRelation(),
    new OtherRandomJunk()
);
 
// Get only Entity objects
$entitiesOnly = array_filter($objCollection, function($val) {
    return ($val instanceof Entity);
});

In the above example, it may not make sense to create a separate named or global function for this collection filtering, because it may only ever be used in one place. If this is the case, it makes sense to use a closure, and makes the code more concise and readable because everything is all in one place.

Summary

Closures are a game-changer for PHP all by themselves. Throw namespaces and late static binding in the mix as well, and PHP 5.3 reaches a level of power and dynamic flexibility that PHP has never been able to reach before. If you have been sitting on the sidelines, stuck in PHP 5.2 land – you desperately need to upgrade. This is the future of PHP.

Queries are case-sensitive

Fields and queries in MongoDB are case-sensitive:

1
2
3

var test1 = db.test.find({'tags': 'jquery'}).count();
var test2 = db.test.find({'tags': 'jQuery'}).count();
test1 == test2; // Output is false - they do not query for the same information

This can cause some headaches if you don’t normalize user input ahead of time. Imagine you already have several posts tagged with ‘NoSQL’ and users enter ‘nosql’ in a tag search box. If you don’t normalize how the data is stored internally (like lowercase all tags), your user will see a much smaller set of posts than they are expecting to see. This is something you don’t have to worry or even think about with MySQL and most other relational databases.

If you can’t normalize the stored data, but still want a case-insensitive query, then you must perform a slower regular expression query:

1

db.test.find({'tags': /jquery/i}); // Note the 'i' flag for case-insensitive

Data is type-sensitive

Data stored within MongoDB knows it’s type. There is a small but significant difference between these two records:

1
2

{'count': 102}; // 'count' is stored as an int
{'count': "102"}; // 'count' is stored as a string

This is obvious to any programmer when presented like this, but what may not be obvious is that this also affects how you can query for these records:

1
2

// This returns 1 instead of 2, because it only matches the integer value
db.test.find({'count': 102}).count();

This is due to how MongoDB stores documents internally with BSON (Binary JSON), using various MongoDB data types. This means – like the point above – that you must pay attention to how you are saving data into MongoDB, because it will affect how you can query for it later.

Documents sizes are capped at 4MB each

This isn’t a big issue for most people, but it’s something to be aware of if you plan on storing large chunks of text or nesting a bunch of objects inside a single document. Nesting comments inside article documents is a particular approach that may give you pause knowing there is an upper threshold on document size.

Note that this limitation is not an issue for storing files in MongoDB because GridFS transparently divides the contents of files larger than 4MB across multiple documents.

Only one index is used per query

Simply adding more indexes doesn’t always help queries run faster. MongoDB can’t use multiple indexes together like MySQL and other RDBMS can (see “Index Merge Optimization“). This means that if a query is selecting or sorting based on multiple fields, a compound index should be created with those fields for the query to run most efficiently.

MongoDB is for high-memory and 64-bit systems only

Although MongoDB can be downloaded, compiled, and installed on 32-bit systems, it should never be run in production on them. This is because MongoDB stores all indexes in memory as well as memory-mapped files for all disk I/O for increased speed and throughput. While these two facts aren’t “gotchas” themselves – they are clearly explained on the website – it does mean that MongoDB can quickly use a lot of memory, especially as the size of your database grows and becomes significant. Since 32-bit systems have an effective 3GB memory limit of addressable memory space, they prevent you from being able to add more memory as the size of your database grows. This is also something to think about if you plan to run MongoDB on a small VPS with limited memory, even if it is 64-bit. You may be forced into a memory upgrade sooner than you are prepared for if your database is large or rapidly growing.

Subtle Differences

When starting out with MongoDB, it’s easy to draw a lot of parallels to MySQL and make a lot of assumptions based on those similarities. Collections are kind of like tables, fields are kind of like columns, a document is kind of like a row. You may find yourself going on to make more assumptions about how it’s storing data, how you can query it, what you can do with it, etc. without even knowing it. So while MongoDB has a lot of similar features and is one of the easiest NoSQL databases to transition to from a relational database, it has some very distinct differences “under the hood” that you have to be aware of and plan for ahead of time. The MongoDB documentation is well-written, and is pretty good at explaining any potential differences or “gotchas”, so make sure to read it thoroughly before making the jump – and watch that first step.

Once you fully get the NoSQL viewpoint and the implications it has on the future of data storage, you have one of those “why didn’t anyone think of this sooner?” moments. And yes, I know key/value stores like memcached existed long before this whole new “NoSQL” movement, but it’s not quite the same thing.

Object Databases

Object databases are an interesting case. They are in the “NoSQL” category and solve the same problem other NoSQL databases do – creating a storage mechanism that fits your data instead of making your data fit a predefined rigid storage mechanism. So why didn’t they catch on? What gives? It’s anyone’s guess why object databases didn’t catch on and achieve widespread adoption, but one thing is for sure – object databases really missed the boat while other NoSQL database technologies are running rings around them.

The primary problem is that most object databases are designed for a specific language, like Java or .NET. Some have more language support than others, but the problem is still the same – by integrating in directly with a language’s object model they depend on specific language implementations, which severely limits adoption. They solve the impedance mismatch problem that RDBMSes present, but fail to provide language-agnostic data persistence and access, effectively tying their use to specific technology stacks and platforms.

The Best of Both Worlds

NoSQL databases are gaining traction like no other database technology has in over 30 years. The reason is that good NoSQL databases solve both key data storage problems: impedance mismatches AND language-agnosticism. By storing the data in an intermediary format like JSON (or BSON) and allowing custom file content types, the focus is on the actual data itself instead of specific technologies or data models. The technology stack becomes irrelevant, and the walls to gaining user adoption crumble.

The bottom line is that NoSQL databases are not just the latest fad. They represent a fundamental paradigm shift in data storage and are an entirely new way of thinking about how to store and access your data in a way that makes sense for your actual usage. NoSQL databases are absolutely something you should be paying attention to and following closely – they are a strong contender to the RDBMS model and will likely become the de-facto data storage choice for most new web applications within a decade.

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

class BobUser
{
	public $name = 'bob';
	public $publicFlag = true;
	protected $internalFlag = true;
 
	public function getFields()
	{
		$getFields = create_function('$obj', 'return get_object_vars($obj);');
		return $getFields($this); // Returns only 'name' and 'publicFlag'
	}
}

We can also do this the PHP 5.3 way with a much nicer-looking closure:

1
2
3
4
5
6
7
8
9

class BobUser
{
	// ...
	public function getFields()
	{
		$getFields = function($obj) { return get_object_vars($obj); };
		return $getFields($this);
	}
}

“… So a blogging platform won the content management system award? How sad is that?”

My knee-jerk “how sad is that?” reaction comes not because I don’t think WordPress is worthy, but because of what it implies about the state of other open source CMS projects. The reaction comes from the fact that a blogging platform is kicking your CMS’s ass in its own category.

WordPress bridges both the blogging and CMS categories due to the ‘Pages’ feature, and is extremely useful for managing a blog-focused website. Mostly. That is, until you want to do something that a CMS should be good at, like have an event calendar, custom form, photo gallery, etc. – which is why WordPress is not focused on being a CMS in the first place. Yet it does such a better job at the basic things like creating new pages, tagging, categorizing, comments, and having custom SEO-friendly URLs out of the box that it edged out other software projects like Drupal MODx and Joomla! SilverStripe whose sole focus is content management. Sad indeed.

The fact that I can go through literally hundreds of open source content management systems and still end up settling on WordPress because I know it’s the only one that won’t totally confuse my client is what’s sad. Usability and ease of use matter. They are the number one feature to the end user. If you’re involved in a CMS project, you need to do better. A lot better. Right now.

UPDATE: Some commenters have pointed out that the awards website has a specific rule:

Previous winners of the Overall category are not eligible for the Overall category in 2009. Previous winners compete amongst one another in a separate Hall of Fame category designed specifically for them.

Since both Drupal and Joomla! have won the award previously and thus were automatically excluded, I replaced their names with the CMS projects that were 2nd and 3rd behind WordPress (MODx and SilverStripe) instead. The premise of the post still holds true.

Object Oriented Apologetics

In defense of object-oriented programming – How and why you should use object oriented programming for your next project.This talk is for PHP programmers who are just learning about object oriented code, who cling to old excuses(“object oriented code is slower”), or who are otherwise unconvinced of its usefulness. Concrete real-world examples of commonscenarios and challenges that programmers face will be presented, and how taking an object oriented approach is better than a proceduralone in most cases. Copious code examples in both object oriented and procedural approaches will be provided throughout, and thedifferences and benefits of the object oriented approach will be explained.

Download Object Oriented Apologetics on SlideShare

If you were in the talk, please rate it on Joind.in

The CodeWorks Experience

All in all, the CodeWorks roadshow Dallas stop was much smaller than I expected. There were about 20 people in the talk I gave. I suppose it was both a good a bad thing. On one hand, I had a lot of fun connecting with the other speakers and attendees on a more personal level than I would have had the opportunity to do otherwise. I met a lot of new people in the PHP community that I will probably stay connected with on some level, even if it is just Twitter and IRC. We had a lot of fun the night before the presentation day eating together and hanging out.

On the other hand, I know that as a business, the relatively low attendance levels coupled with the high travel expenses could mean that something like this can’t happen again, which is a shame. This was one of the best efforts I have seen in a while to really lower the price of the conference for attendees by bringing the speakers directly to their cities or at least ones that are close by. Going to ZendCon, for instance, could easily cost up to $2,500 for the whole trip with airfare, hotel stays, and food, if not more.

The bottom line here is that CodeWorks was a good conference that offered a great value for your money. I had a great time meeting and connecting with new people and finally meeting people in real life that I had been communicating with for years. I learned some new things and finally got the kick in the pants I needed to jump into Test Driven Development, thanks to Jason Sweat’s TDD tutorial and hand-holding.

Now I’m just looking forward to php|tek in May 2010.

I was able to arrive at this solution by combining the one-line comment with the comment block in a way that takes advantage of the rules the different types of comments have to follow.

The One-Line Comment

One-line comment rules dictate that everything after the comment characters must be ignored for the rest of that line. They look like this:

1
2
3
4
5

// My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";

The Block Comment

Block comment rules dictate that once the beginning characters are started, everything up until the ending characters is ignored. They look like this:

1
2
3
4
5
6

/* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
*/

Combining The Two: The Best of Both Worlds

Using both those comment style rules, we can combine the two comment styles in a way that will allow us to comment and un-comment a block of code with by adding or deleting a single character. The trick is to make both the beginning and ending lines both single-line AND block style comments, like so:

1
2
3
4
5
6

//* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
// */

In the above example, you notice that the code will still run – it’s not commented out because the first line is following the rules of the single-line comment – ignoring the block comment declaration on the same line. By removing the first backslash at the beginning of the block, we can comment out the entire code block by enabling the block comment style instead of the single-line style. The last single-comment line is ignored because the block comment rules ignore everything up until the end block comment declaration at the end of the line:

1
2
3
4
5
6

/* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
// */

So a single character – a backslash at the very beginning of the block declaration can now comment or un-comment the entire block by switching the comment rules back and forth between single-line and block style. The code examples provided are in PHP, but this trick will work with any language that supports both single-line and block style comments.