Bradley Holt

The Future of CouchDB and Couchbase Server

2012-01-05T19:42:03Z

“What’s the future of CouchDB? It’s Couchbase.” —Damien Katz

“The future of CouchDB is CouchDB.” —Noah Slater

First of all, don’t panic. The Apache CouchDB project is thriving. There are plenty of core contributors who are dedicated to the project. If you’re using CouchDB, you’re fine. If you’re considering using CouchDB, you’ll be fine. CouchDB has a bright future ahead of it. Couchbase has repeatedly said that they’re not the CouchDB company, so this shouldn’t be a surprise to anyone.

My interpretation of this announcement is that CouchDB is forking. Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

CouchDB has two futures: CouchDB and Couchbase Server. Traditionally, forking a project in this manner has been considered a Bad Thing. From The Jargon File entry for forked:

An open-source software project is said to have forked or be forked when the project group fissions into two or more parts pursuing separate lines of development (or, less commonly, when a third party unconnected to the project group begins its own line of development). Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.

In my humble opinion, forking should no longer be considered a Bad Thing. Distributed revision control systems, such as Git, have made it much easier to merge changes back-and-forth between forked projects. If an individual or organization wants to take a project in a different direction, great! It sounds like Couchbase Server will be designed to meet a set of needs that are not being met by CouchDB. If so, a fork is perfectly appropriate as now both sets of needs can be met.

Boston PHP Northeast Conference

2011-12-09T23:51:25Z

I’m excited to be able to announce that the first ever Boston PHP Northeast Conference will be taking place on Saturday, August 11^th and Sunday, August 12^th at Microsoft’s NERD Center in Cambridge, MA. This regional event is intended for PHP beginners, enthusiasts, and professionals alike. The current plan is to have four tracks:

Core PHP
Web Development
Training
User Experience (UX)

Boston PHP will be hosting the event in partnership with other northeast regional user groups including the Burlington, Vermont PHP Users Group (which I organize) and the Atlantic Canadian PHP User Group. We’re still early in the planning stages, so there will be more details to come later. If you’re interested in speaking, have ideas for the event, or are interested in sponsoring then please send a message to Boston PHP.

The Twelve-Factor App Applied to PHP

2011-11-29T16:32:23Z

If you develop web apps, I encourage you to check out The Twelve-Factor App. This is an excellent resource for anyone building and deploying software-as-a-service. PHP has great support for many of the twelve-factors. I want to take a look at specifically how each factor may be applied to a PHP application.

I. Codebase

“One codebase tracked in revision control, many deploys”

There’s really not much here that would be different in PHP versus any other language. Who isn’t using some form of revision control these days?

II. Dependencies

“Explicitly declare and isolate dependencies”

There are a few tools available to PHP developers to help manage dependencies. The PEAR package manager may help here, but has its flaws. Pyrus, the PEAR2 package manager, looks promising. There’s also Composer. I’ve heard of people using their operating system’s package manager (e.g. RPM) to deploy their PHP applications and manage dependencies. I’m not sure if there any tools in PHP to enforce dependency isolation.

III. Config

“Store config in the environment”

The simplest option here is to use environment variables. Many frameworks, including Zend Framework, allow you to have environment-specific configuration such as development, test, and production. This is not recommended for twelve-factor apps as it doesn’t scale as new environments are added.

IV. Backing Services

“Treat backing services as attached resources”

There’s not really anything to say here that’s specific to PHP.

V. Build, release, run

“Strictly separate build and run stages”

Phing or the more general-purpose Ant could work here. Even though it’s not written in PHP, there’s no reason why you couldn’t use Capistrano for this. I don’t think the run stage typically applies to PHP, as it happens implicitly as part of the release stage. However, there are tasks such as flushing the APC cache (if apc.stat=0) that might be considered part of the run stage.

VI. Processes

“Execute the app as one or more stateless processes”

PHP processes are already stateless and shared-nothing. This makes PHP a great fit for twelve-factor apps. Memory space or the filesystem should be used as a short-lived, single-process cache. If you’re using an asset manager, such as Assetic, then any assets should be compiled and cached during the build stage.

VII. Port binding

“Export services via port binding”

I don’t think port binding applies to PHP applications—at least not in the way it’s meant in twelve-factor. PHP relies on a web server and uses something like FastCGI or PHP-FPM to communicate with the web server. PHP 5.4 will have its own built-in web server, but this is intended for development use only. It’s really the combination of PHP and its web server that will be bound to a port. This brings up challenges when it comes to dependency management, as the web server itself is now a dependency.

VIII. Concurrency

“Scale out via the process model”

I’m not sure how processes would become first-class citizens in a PHP web application. However, each individual request/response cycle is handled by its own process. In that regard, PHP already uses the process model.

IX. Disposability

“Maximize robustness with fast startup and graceful shutdown”

PHP processes are very disposable. Again, this is just part of how PHP works.

X. Dev/prod parity

“Keep development, staging, and production as similar as possible”

Nothing specific to PHP here. Although, it’s not uncommon for PHP developers to use SQLite in development and MySQL or PostgreSQL in production. This is not recommended for a twelve-factor app—use the same software and versions of backing services in all environments.

XI. Logs

“Treat logs as event streams”

There are tons of logging options in PHP. Zend_Log_Writer_Stream lets you send log data to a PHP stream. Alternatively, StatsD and the PHP StatsD library look pretty good.

XII. Admin processes

“Run admin/management tasks as one-off processes”

This is easy enough in PHP. If you want an interactive shell with readline history, tab completion, and quick access to documentation then check out phpsh.

CouchApps at CouchConf NYC

2011-10-27T20:05:52Z

Here are the slides from Monday’s CouchConf NYC session on CouchApps with CouchDB, JavaScript and HTML5:

CouchConf NYC CouchApps

View more presentations from Bradley Holt

Domain-Driven Design at ZendCon 2011 UnCon

2011-10-19T00:15:04Z

Here are the slides from today’s ZendCon UnCon session on Domain-Driven Design:

ZendCon 2011 UnCon Domain-Driven Design

View more presentations from Bradley Holt

If you were in this session, please give me feedback on Joind.in.

Learning CouchDB at ZendCon 2011

2011-10-18T00:37:55Z

Here are the slides from today’s ZendCon tutorial on Learning CouchDB:

ZendCon 2011 Learning CouchDB

View more presentations from Bradley Holt

You can instead download the PDF version, if you’d prefer.

If you were in this session, please give me feedback on Joind.in.

Burlington Telecom Advisory Committee

2011-10-05T20:17:22Z

This past Monday evening I was Appointed by the City Council of the City of Burlington, Vermont to the Telecommunications Advisory Committee. In this volunteer position, my role is to advise the City Council on matters related to Burlington Telecom, a municipally owned telecommunications services provider.

I have many of my own opinions about Burlington Telecom, its role in our community, and its future. As a member of this committee, I’m more interested in bringing the opinions of others forward. If you’re part of the Burlington community, please share with me your thoughts about Burlington Telecom. What do you want out of Burlington Telecom? What attributes of Burlington Telecom are important to you? Please share these thoughts publicly on Google Moderator. I’ve shared a few of my own thoughts to get things started.

As I mentioned, I have my own opinions about Burlington Telecom. To understand further where I’m coming from, I’ve included here a truncated version of the letter I sent applying to be on the committee.

Dear City Councilors:

Enclosed for your consideration is my application to join the Burlington Telecom Advisory Committee. I was one of the first beta customers when Burlington Telecom launched. I am now both a residential and a business customer. I was enthusiastic about the vision for Burlington Telecom from the moment I first heard about it. As someone who spends a good portion of his personal and professional life online, I understood immediately the cultural and economic benefits that an advanced fiber optic network could bring to our city.

…

Burlington Telecom is the 21st century equivalent of rural electrification, at a local scale. Like electricity in the 1930s, private companies are unwilling to invest in a telecommunications infrastructure that will spur economic growth in less populated areas. Companies like Verizon have gone so far as to divest their networks in non-metropolitan areas so that they don’t need to build-out modern broadband infrastructure in these places.

The Burlington Electric Department proudly states, “public power since 1905.” The City of Burlington created the Burlington Electric Department a full 30 years before the forming of the Rural Electrification Administration at the federal level. The City of Burlington seemed to have similar foresight when they created Burlington Telecom. Perhaps Burlington Telecom is an idea that is ahead of its time. Maybe we should wait several decades for a national initiative on telecommunications infrastructure. Alternatively, we can be proud of what has been done with Burlington Telecom. There are serious challenges to maintaining Burlington Telecom as a public resource, but these are challenges worth addressing.

Like the Burlington Electric Department, I believe that the people of Burlington can again be proud of Burlington Telecom. During Tropical Storm Irene, my house lost power for only 30 minutes. This was a point of civic pride for me and provided an exemplar of how our public utilities can be operated. Burlington taxpayers have regularly voted to fund Burlington Electric Department initiatives around green energy, energy efficiency, and general infrastructure improvement. If people can be proud of things as intrinsically boring as utilities and electricity, then we can be proud of a state-of-the-art fiber optic network that provides high-speed Internet, television, and telephone services.

As a member of the Burlington Telecom Advisory Committee, I hope to understand more fully the challenges facing Burlington Telecom and advise the City Council on addressing these challenges while maintaining Burlington Telecom as the vital public resource that it is. I am an advocate for a vision of Burlington Telecom not as a burden, but as a source of great opportunity for our city.

…

CouchApps at jQuery Conference Boston 2011

2011-10-02T15:15:34Z

Here are the slides from today’s jQuery Conference presentation on CouchApps with CouchDB & jQuery:

jQuery Conference Boston 2011 CouchApps

View more presentations from Bradley Holt

If you were in this talk, please give me feedback on SpeakerRate.

Speaking at CouchConf NYC

2011-09-29T16:33:58Z

I’m pleased to announce that I’ll be speaking at CouchConf New York City on October 24, 2011. This event is part of the CouchConf World Tour presented by Couchbase. My talk will be on CouchApps with CouchDB, JavaScript and HTML5. From the talk description:

In this talk we’ll see how to build CouchApps using CouchDB, Javascript, and HTML5. We’ll look at related tools such as the couchapp command ine tool, the Evently jQuery plugin, the CouchDB API jQuery plugin, the CouchApp Loader, Pathbinder, and the Mustache templating framework.

Bradley Holt

The Future of CouchDB and Couchbase Server

Top Five Posts of 2011

5. CouchDB and Domain-Driven Design

4. Addressing the NoSQL Criticism

3. Testing PHP 5.4

2. Exploring RabbitMQ and PHP

1. CouchDB jQuery Plugin Reference

Boston PHP Northeast Conference

The Twelve-Factor App Applied to PHP

I. Codebase

II. Dependencies

III. Config

IV. Backing Services

V. Build, release, run

VI. Processes

VII. Port binding

VIII. Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs

XII. Admin processes

CouchApps at CouchConf NYC

Domain-Driven Design at ZendCon 2011 UnCon

Learning CouchDB at ZendCon 2011

Burlington Telecom Advisory Committee

CouchApps at jQuery Conference Boston 2011

Speaking at CouchConf NYC