Our PHP on Windows contest is drawing to a close with two beautiful finalist packages that showcase the power of PHP on Windows—all we need now is your help to crown the winner!

• Cont-xt is an ambitious new open source content management system aimed to end the “backend” editing paradigm for good. All content editing is done directly in-place and on-page through drag-and-drop JavaScript and AJAX methods. Templates define regions that content modules can be dropped into. The modules can be any amount of any type, in any order, in any defined region per page.
• Manuscript is an easy-to-use, powerful content and document management system with support for Microsoft SQL Server, SQLite and works with PHP 5.2 or 5.3 cross-platform.

Which one will win? Only you can decide by voting for your favourite—and in so doing, you might be one of 50 lucky winners that take home a free one year subscription to php|architect (no strings attached!)

Matt Butcher, notes author and contributor to open source projects, talks about Drupal.

This is part of the spring TEK·X webcast series and is sponsored by Microsoft and hosted by php|architect.

Today, Noah Slater, release manager of the Apache CouchDB project, announced the release of CouchDB 0.11.0. CouchDB is a document-oriented database and is one of the poster children of the NoSQL movement.

The latest release of CouchDB has a long list of changes, including:

• Added support for building a Windows installer as part of “make dist”
• Added optional “raw” binary collation for faster view builds where Unicode collation is not important
• Improved view information objects
• Improved speed and concurrency of config lookups
• Various improvements to the Futon UI

CouchDB 0.11.0 is the first release of the software that does not carry the “alpha” or “beta” tag. Whether this means the product can be considered production-ready is up to you, but the CouchDB wiki lists quite a number of projects already using the software.

I recently sat down and started playing with CouchDB, trying to wrap my head around this new way of “doing databases.” The CouchDB Wiki is a good place to start, although I found that it seems to presume a decent amount of prior knowledge (a definite hindrance to me, since I lack some of that prior knowledge!).

There’s also an online version of O’Reilly’s CouchDB: The Definitive Guide, and I found this useful to get myself started—although you should note that a few places were a tad out-of-date relative to the latest release (at least, that’s how it appeared to me). Nothing critical, though.

If you haven’t yet tried CouchDB, I recommend you do so; it’s definitely a different way of doing things than traditional relational databases, and it takes some getting used to, but it feels very natural after a while. Of course, it’s not necessarily going to outright replace your existing SQL-based data stores, but for the right project, it’ll surely be useful.

You can download CouchDB 0.11.0 from the CouchDB downloads page. You’ll also find a list of the changes incorporated in 0.11.0 there.

The MongoDB team has just announced the release of version 1.4.0 for production. The new version is available for download at: http://www.mongodb.org/display/DOCS/Downloads. Notable updates found in the released include: background index building, better detection of regular expressions so the index can be used in more cases, fast new slaves from snapshots, REST interface is off by default for security (—rest to enable), can rotate logs with the logRotate db command, and partial matching of array elements with $elemMatch, to name a few. The full change log is available at: http://jira.mongodb.org/secure/IssueNavigator.jspa?requestId=10080. This release was announced on the MongoDB blog and also includes benchmarks comparing version 1.2 with version 1.4RC2. The results show that version 1.4RC2 is comparable, if not slightly faster, than version 1.2 in most things, like single threaded query performance and insert performance (which showed an increase of 10-30% vs 1.2). Not everything was faster, though, as creating an index after importing your data is generally faster than before, and this is even more so the case in 1.4.

To learn more about the new features and about MongoDB in general, check out Kristina Chodorow’s blog post on “AntidisestablishmentSQLism“. Kristina is a core contributor to MongoDB and wrote/maintains the PHP driver for it. Kristina also did a webcast for our Tek·X series on how, why, and when to use MongoDB.

Talking about the NoSQL movement is like talking about a “NoC++” movement: people not using C++ have very little else in common with each other.

For instance, some people say that NoSQL is obviously all about ACID (atomic, consistent, isolated, durable) vs. BASE (basically available, soft-state, easy). Other people say it’s all about scalability, whereas others say it’s all about distributing data, but not necessarily horizontal scaling. Some people say it’s not about scale at all, but to get away from modelling data as rows in a table.

It’s a recent “movement,” but databases that have been around for decades are claiming to be NoSQL along with the ones hacked together in the last few months. Databases that are no more complex than Memcached are grouped with those that could power every aspect of a complex website on their own. There are databases ready for production deployment and others that are still in beta, alpha, or haven’t even been released.

The people themselves also vary widely: some of the developers are brilliant geeks who know scaling inside and out. Others are DBA-types who have been dealing with MySQL issues for years. Others are conceited jerks who think that, because they read the Dymano/Bigtable/PNUTS paper, they’re the only ones who understand the issues.

As I have read the Dynamo/Bigtable/PNUTS paper, here are the main issues:

Horizontal scaling

This is a biggie but, as people who like relational databases always point out, you can scale relational databases. It’s just very difficult and sacrifices a lot of the features that make them useful to start out with. Some NoSQL databases just scale much more easily and naturally.

Multi-master

Again, you can run MySQL as multi-master, but it’s a pain. Many NoSQL databases list multi-master as a feature, but a lot of programmers who think they want multi-master probably won’t like the reality of it. A quick quiz: does your heart sing at the thought of programming conflict resolution logic for every possible stale data scenerio? Then multi-master may be for you. (I’m not a big fan of multi-master, someone else may want to defend this one.)

Data representation

Rows can model a lot, but unless you’re programming accounting apps, they’re unlikely to be a natural fit for your data. More often than not, data is much more interesting and complex than a row (such as a graph of friends, a tree of links, or overlapping timelines of events). Sometimes, data is very simple (e.g., a cookie used to look up a session). Sometimes it changes over time. Many NoSQL databases give you a more flexibile way of modelling data.

Speed

Relational databases are pretty heavyweight with all sorts of data safety guarantees, which is unnecessary overhead for a lot of applications. Some NoSQL databases can store things as fast as Memcached (although not when they flush to disk… they are limited by physical laws, despite what their developers might claim). If you have something like page statistics or logging, using a relational database might just be slowing you down.

At this point, NoSQL databases are huddled together against the overwhelming presence of relational databases. However, NoSQL is an unnatural and, in many cases, uneasy alliance.

Photo credit: Great Protest Signs by didbygraham

According to the official documentation, PHP namespaces have been designed to prevent name collisions between classes from different packages and to avoid the use of very long names in the code to refer to classes or functions—nobody really wants to have to deal with something called Zend_Db_Adapter_Mysqli or PHPUnit_Framework_Constraint_IsInstanceOf, after all. This means that namespaces help a developer write code that is both more concise and clearer—a direction which is always an improvement towards expressiveness.

Within the PHP implementation of namespaces, these names will be ideally refactored to Zend\Db\Adapter\Mysqli and PHPUnit\Framework\Constraint\IsInstanceOf, where \ is the namespace separator. In the codebase, however, there will typically be very few references to these classes with their fully qualified name, because it is possible to import entire namespaces in a script and then use the class names directly, making the code easier to follow and unambiguous to write.

In fact, the definition of a namespace class itself does not contain its fully qualified name. For example, this would be the source file of an hypothethical MyLibrary\TypeOfComponents\MyClass class:

<?PHP
namespace MyLibrary\TypeOfComponents;

class MyClass
{
    // ...
}

The convention when writing namespace-enabled code is that of creating a folder structure that reflects the individual components of a namespace (for example, MyClass would be in the MyLibrary/TypeOfComponents directory. This helps standardizing the autoloading process.

How namespaces work

Namespaced name resolution has been retrofitted in PHP 5.3 by inserting a processing mechanism at compile time. All the references to classes and functions in a namespaced source file are parsed before the actual execution of the PHP script and substituted with fully qualified names.

But what rules does the name resolution process follow? You can better understand this process with a filesystem metaphor:

• Every name that does not start with a backslash is interpreted as a relative reference (path) from the current namespace (directory). For example, in the source code above, MyClass would refer to MyLibrary\TypeOfComponent\MyOtherClass with the unqualified name MyOtherClass. It can also refer to MyLibrary\TypeOfComponents\SubNamespace\ACollaborator with the qualified name SubNamespace\ACollaborator.
• Names that start with a backslash are always relative to the global namespace (to the root directory), and are always resolved to the literal specified value. For example, \PHPUnit\Framework\TestCase class is resolved to the fully qualified name of PHPUnit\Framework\TestCase.

Note that the name resolution process examples above are limited to classes, but the same concepts apply to methods.

Pre-PHP 5.3 code will not, of course, have any namespace defined in it and will continue to work as before, residing in the global namespace because there are no namespace keywords.

Fallback

There is however an exception to the resolution process I have just described: constants and functions that are defined in the global namespace—including all built-in PHP functions like is_array() and strlen().

If we had to refer to each function using its fully-qualified name and prefix them with a backslash every time we need to use them, our code would pretty soon become an unreadable jumble of symbols. For example, you’d have to write \strlen() in all namespaced code, because the strlen() function is defined in the global namespace, and not in the current one.

Luckily, function and constant name resolution falls back to the global namespace when they are not found in a more specific one that is currently available. Thus, you can call strlen() from namespaced code without using a leading backslash—as long, of course, as you do not have a strlen() function defined in the current namespace that will shadow the global one.

This fallback rule does not apply to classes and interfaces: SPL‘s constructs such as Iterator and ArrayObject, for example, must be written as \Iterator and \ArrayObject in namespaced code, or they won’t work.

You can think of this rule as having these functions defined in your PATH environment variable: no one refers to the ls (dir at a Windows shell prompt) command as /bin/ls.

Importing classes

Being able to refer to classes in the current namespace without their fully qualified name is a good improvement over the long class names we had to deal with before namespaces, but we can expand the name aliasing further.

Import statements that create aliases to fully qualified names can be inserted after the namespace keyword, which is always the first language construct at the beginning of the file when present. These aliases are local to the file. Consider this example:

<?PHP
namespace MyLibrary;

use ExternalLibrary\Filter\Int as IntFilter;
use ExternalLibrary\Filter\NotEmptyString;

In a source file with these use statements, you can refer to the IntFilter and NotEmptyString classes without any syntax noise. If an explicit alias is not defined, the base name (NotEmptyString) is used as a default value, and it is usually sufficient.

Again, we can extend the filesystem metaphor to cover the import functionality. Aliases can be compared to symlinks from the current directory to an absolute path: you are able to refer to the symlink with a short base name instead of using a long absolute path.

Importing class and function names makes namespace very efficient to employ. The fully qualified name of an external class is hidden from the source code and extracted at the top of the file: if it changes, it is easy enough to update a single instruction instead of refactoring large areas of code. Moreover, with this approach the external dependencies are explicitly listed in a single point for every source file.

Dynamic features

Name resolution happens at compile time; therefore, every time a class is referenced dynamically, such as when using a variable variable or passing a parameter to (for example) class_exists(), you must be a fully qualified class name:

$instance = new $class();
$boolean = class_exists($class);
$boolean = $instance instanceof $class;

In these use cases, by the time the code is executed, the resolution process will have already occurred and, obviously, the compiler will have no way of telling whether $class contains a class reference that must be resolved; therefore you must make sure that it contains a full-qualified class name in order for things to work properly.

Despite their simplicity, some of the less-obvious aspects of namespaces can be difficult to understand when you’re first starting out. If you have any other doubts, you can read the FAQ from the official manual, which contain much more code than my examples, or ask a question in the comments.

It seems that everyone has a few USB flash drives nowadays. Whether you call it a flash drive, a thumb drive, a stick, or something else, it’s likely that you have some sort of portable storage in your pocket or bag. The question is, what do you have on that flash drive? And what apps could you have, but maybe haven’t thought of putting on your drive?

An informal poll of my fellow php|architect bloggers on what they currently have on their flash drives garnered some interesting responses, ranging from (ahem) “time-shifted” television programs to a full-on OS X client capable of running from a USB drive. But, after doing some digging, I’ve come up with my own suggestions on what you might consider putting on your own drive.

Things that aren’t applications

First, let’s talk about some things you might want to keep on your drive that aren’t applications. Included here are things like database backups (I keep a MySQL dump on my drive for those times when I need to do work from home), configuration files, document templates (say, invoices and the like), perhaps your PGP/GPG key, and things of that nature. Essentially, this category includes anything that might help you set up some sort of working environment given that the necessary applications are in place.

You might also consider things like a slide deck (or PDF equivalent) of talks that you gave at a conference or seminar, or conversely the same for a talk that you attended—so that you always have that information with you.

Finally, in a similar vein, if you’re an ebook-reading type of person, and you have PDFs of your favorites, you might toss those on the flash drive as well. Of course, if you have a dedicated ebook reader, then you probably have this item covered.

Operating systems

As I mentioned earlier, one of my fellow bloggers mentioned having OS X on a flash drive. It’s a fairly straightforward process to get Leopard on a flash drive, but know that you’ll need one with a lot of space—at least 8 GB.

If you’re not the OS X-type, then perhaps Linux is more your speed. Here, though, I’ll point you at the Wikipedia article on creating Live USB systems, since there are myriad ways you might put Linux on a USB drive.

And if you’re a Windows XP user, you might find this guide useful on installing XP onto a flash drive and running it from there. (A quick search didn’t yield useful info on Vista or Windows 7, but it’s certainly possible that there’s something out there.)

Applications (yes, finally!)

“Portable application” is the term for an application that leaves zero (or nearly zero) footprint on the host system; does not require itself to be installed on the system to run; and carries its settings along with it on the USB drive or other such medium. Here, again, Wikipedia has a great list of portable software, but I’d like to mention a few standouts. Note that some of these come from PortableApps.com, which might be right up your alley if you’re a Windows user.

• Mozilla Firefox, Portable Edition: One of the PortableApps.com member applications, this portable version of Firefox just might come in handy.
• Eclipse: Using Eclipse as your IDE? Then this guide ought to be of use if you’d like to run it from a flash drive.
• GIMP Portable: Another of the PortableApps.com apps, the fairly lightweight GIMP image editor is a great choice for tweaking graphics and whatnot.
• EasyPHP: Want an alternative to XAMPP? Try EasyPHP instead, which claims to offer the ability to run from a USB flash drive.
• Notepad++ Portable: Also on the PortableApps.com list, the Notepad++ text editor is a great alternative to other editors.

What else?

Since USB flash drives seem to be a dime a dozen nowadays (well, nearly so), you could even have USB flash drives set aside for single purposes rather than carrying them around in your pocket all the time. It seems that Microsoft is going to allow USB storage on its Xbox 360 console, so you could pop your drive into a USB port there and just leave it. You might also have a few lying around within things like the ATV USB Creator, which lets you do things like prep your Apple TV for a Boxee install, and just leave that drive in a safe place always ready for use (rather than having to copy the data off, wipe it, and replace data later).

Whatever use you find for your flash drive, I hope that these suggestions have at least whetted your appetite. Let us know in the comments what other uses you have for your flash drive!

Image credit: USB Flash Drive by Flickr user Ambuj Saxena.

Twitter is a great place where you can follow what happens in the PHP community. A good selection in your list helps you keep the noise level low and gives you the opportunity to closely communicate with the VIPs of the PHP community.

Here are ten vocal PHPers to include in your list if you want to know more about PHP development and be promptly updated on breaking news by their original sources, in no specific order:

• Rasmus Lerdorf (@rasmus): Danish programmer mostly famous for having created the PHP language in 1995. He’s still the leader of the development of PHP 5 and PHP 6 as a Benevolent Dictator For Life.
• Terry Chay (@tychay): the “PHP Terrorist,” and the greatest advocate of  PHP over Ruby. Worked on Tagged and now at Automattic, the company that created WordPress. He knows how to scale PHP applications.
• Andi Gutmans (@andigutmans): co-founder of Zend Technologies, the largest company behind PHP development. Ever heard of them? The nd in Zend comes from Andi’s first name.
• Derick Rethans (@derickr): developer of PHP core and of the very handy Xdebug extension. He will likely be the next PHP release manager.
• Matthew Weier O’Phinney (@weierophinney): lead developer of Zend Framework, the PHP framework from the company that made PHP what it is now.
• Fabien Potencier (@fabpot): lead developer of Symfony and CEO of SensioLabs, were both Symfony and Doctrine were born. Symfony is along with Zend Framework one of the largest open source PHP frameworks, while Doctrine is an object-relational mapper.
• Sebastian Bergmann (@s_bergmann): creator of PHPUnit, the testing framework for PHP applications that became a standard as the xUnit incarnation for this platform.
• D. Keith Casey, Jr. (@CaseySoftware): founder of CaseySoftware; PHP and web2Project developer, organizer of the TEK·X conference.
• Cal Evans (@CalEvans): worked at Zend and IBuildings, major PHP companies. Former host and face of ZendCon. An icon of the PHP community.
• Marco Tabini (@mtabini): creator of php|architect and of the Blue Parabola consulting company; one of the most respected voices in the PHP landscape.

Who did we miss? What’s on your list of PHP notables? Sound off in the comments and let us know!

Disclaimer:  Marco Tabini, Keith Casey and Cal Evans are involved in the publishing of this website.

A few years ago, Joel Spolsky wrote a great article for his blog in which he proved that not only is there a huge productivity difference gap between top-performing developers and mediocre developers but goes on to prove that hiring a lot of mediocre developers instead of a few great developers is not a feasible strategy.

At the very end, he mentions something, in passing, that I have believed and have been saying for years. When discussing the working conditions at Fog Creek, his software company, he had this to say.

“Programmers get private offices, free lunch, and work 40 hours a week.”

If you require your developers to work onsite, the number one productivity tool you provide for them is a door that closes (well, 4 walls and a ceiling to go with it).  Given control of their environment, developers can reach their peak productivity most days and sustain it. Without control, most developers will have a hard time even getting close to their peak.

The reason is as simple as it is obvious: interruptions. In an open-plan office, two people talking to each other can be enough interruption to derail a programmer and set the project back. Phones ring; people get up and walk around; all of these are enough of a distraction to keep a developer from concentrating on the task at hand.

A developer with an office can turn off Twitter, e-mail, IM and Skype to hunker down and work on something. Programmers can get “in the flow,” “in the zone,” or whatever you call it. They can control their environment and shape it to fit their work habits.

In a cube farm, or worse yet, open rooms, programmers have no control over their environment. Without the privacy that an office affords them, it is difficult to concentrate long enough to write a coherent blog post, much less a module for a complex software system.

Companies are always looking to save money—and cutting back on office space often seems a logical move to them. However, it is a penny-wise, pound-foolish strategy. Placing developers in an interruption-driven environment is a guaranteed way to reduce productivity, increase errors and increase the overall cost of producing software.

“Situation Room” environments do have their place in software development. They are useful when rolling out large complex systems that require instant coordination of a lot people and resources. However, open room environments with several islands of tables that serve as desks is the worst type of environment for any task that takes a great deal of concentration like programming.

If you want to increase your developer productivity, put them in offices. If on the other hand, productivity is not that important, by all means, keep them in cube farms or open rooms.

Photo © 2008 Steve Kelley. Released under a Creative Commons license.

Editors Note: In honor of Ada Lovelace day, we have asked core MongoDB developer Kristina Chodorow to be our guest blogger today—and she came through in fine style.

One Friday when I was young and foolish (last year) I committed some code changes, tested nothing, and went home for the weekend. When I got in on Monday, I saw that my coworker had sent out an email to everyone that said “Kristina, you broke the build, you wacky redhead!”

On top of being embarrassed about breaking the build, I was also furious about being called a “wacky redhead” in front of the whole company. Would he call our coworker John a “wacky blonde” or Sam a “wacky brunette”? I’m taking a wild guess at no.

I’m certain that he did not mean anything bad, he just thought it sounded funny (which it does). It’s like the XKCD cartoon about segfaults feeling like waking up with a jerk: when someone talks to me like this, it feels like a segfault.

Almost all of the “sexism” I run into is unintentional and well-meaning, but it’s annoying. Would you tell Larry Wall he was “cute”? Would you send Linus Torvalds a rose (@}–>–) for fixing a bug? Would you ask Joshua Bloch “Are you a busy boy today?”

Before you say something, think, “Would I say this to a guy?” Please, talk to us like we’re programmers, not like we’re women.

I told my coworker that I didn’t like what he said and he understood and apologized. That made me feel better and, as far as I was concerned, closed the matter. Which was when my boss pulled my coworker aside and told him what he had done was inappropriate. Justice ended up being swift and a bit excessive, but everyone lived happily ever after.