First adding modules to nginx requires recompiling nginx so you’ve got to get your hands a little dirty to get it going.  I’m currently running Debian 6 in a hosted environment so I’ll give you the blow by blow based on my config.

Build Process

The first thing we’ll do is cd to /usr/src and grab the source for nginx by issuing the command…

cd /usr/src/
apt-get source nginx

Also make sure you have the following packages installed…

• fakeroot
• debhelper
• dpkg-dev
• autotools-dev
• libssl-dev
• libpq5
• libpq-dev

You’ll also need git installed so that you can grab the sources for the nginx modules you’ll need.  Along with ngx_postgres, you’ll also need rds-json-nginx-module to help with the json production.

cd nginx-x.x.xx/modules
git clone https://github.com/agentzh/rds-json-nginx-module.git
git clone https://github.com/FRiCKLE/ngx_postgres.git

Next you’ll need to see if there are any other dependencies you’ll need for the build which is quite easy on Debian using…

apt-get build-dep nginx

After you know you’ve got everything you’ll need for the build you can modify the ./configure parameters of the build to include the two new modules.  Use your editor of choice to modify the rules file.  Something like vim ../debian/rules

You’ll need to add the –add-module lines to ./configure for the new modules.

--add-module=$(CURDIR)/modules/ngx_postgres \
--add-module=$(CURDIR)/modules/rds-json-nginx-module

That’s it. Now run

dpkg-buildpackage

After a couple of minutes you should have a few .deb files in /usr/src for your enjoyment.  Install the appropriate .deb using dpkg and you’re ready to get ndx_postgres working.

nginx/ndx_postgres Setup

So the build part was pretty straightforward and didn’t take very long but getting it setup and working without any instructions was a bit more challenging.  There are a few configuration examples that come with ngx_postgres that you’ll need to read through to get a feel how a configuration is created and mapped to your tables.

Once you’ve established a basic configuration file for your database tables save the file in the /etc/nginx/sites-enabled/ directory.  The important thing to note is that by default you already have a file in this directory called default. This file does the obvious and creates the default site for a basic nginx installation.  What I didn’t realize was that ngx_postgres wouldn’t work with the default site enabled.  I spent at least an hour going through everything until I finally tried disabling the default file from sites-enabled.  After disabling the default site for nginx.  Everything should start working fine… assuming you’ve formatted your ndx_postgres configuration correctly .

Good Luck.

In file included from psycopg/psycopgmodule.c:32:
./psycopg/psycopg.h:31:22: error: libpq-fe.h: No such file or directory

include_dirs=/opt/local/include/postgresql91

library_dirs=/opt/local/lib/postgresql91

Many a project has gone down in flames because they failed to take the time to really think through a communication plan that educated their stakeholders of the organizational value of their project.  Communication is one of the most important factors to the success of your community. Without communicating your project or program’s benefits and successes, users and stakeholders alike won’t be aware of new offerings, program progress, or the goals and direction of your project.

“The more they know, the more they’ll understand. The more they understand, the more they’ll care. Once they care, there’s no stopping them.”

–Sam Walton

The first step in any Communication Plan is identifying your stakeholders.  This is a key step that is often overlooked.  Many projects and programs focus only on keeping users informed about community news, however its important to look outside your active community members and find the stakeholders that are most important to your continued success.  This may include management, partners, or even other projects and programs only tangentially related to yours.  Putting together this list comes first and will help you not only identify key players but also will help you discover the correct communication channel to reach them.

Next up, you guessed it, identify all your potential communication channels.  Don’t just rely on email or Twitter to get your message out.  Make sure you talk to others within your organization or your partner’s organizations to understand what options are available to you.  For instance does your organization have building monitors that display company news?  Can you schedule webinars?  Does your partner’s have community newsletters that you can contribute articles to?  There are lots of ways that you can communicate to a larger audience usually you just have to look around and ask lots of questions.

The next step is to think through a communication plan that makes sense. Community communications can broadly be grouped into two types, event driven and regularly scheduled.  Your community planning needs to have plans established for each type.

Event driven communication is, as the name aptly implies, usually driven by some event within your project.  This could be the election of new officers, platform upgrades, scheduled downtime, new releases, etc.

Regularly scheduled communications are necessary in projects to keep the general audience and key stakeholders informed about the progress your project or program is making.  This form of communication is where you have a great opportunity to keep your most important stakeholders up to date on progress you’ve made in achieving organizational goals.

The plan below is a basic skeleton plan that identifies which channel will be used to articulate messaging for each communication channel and provides an estimated frequency for communication. Each plan will be different but this should give you some ideas.

Regularly Scheduled Communications

Event Driven Communication

Of course you’ll want to actually go through the Event plan and fill in your own specific information and dates. You may even want to be very specific and include the Communication Channel owner and prep dates that include coordinating with each channel, but using this model you can plan several months ahead and never be caught “reacting” rather than “communicating”.

I recently stumbled across a great post called Communities Manifesto by Stan Garfield that I highly recommend.  In his post Mr. Garfield lays out 10 principals that define community and also has suggestions for helping them grow and mature.

What communities are not …

Two of his principals in particular caught my attention because I’m wrestling with how to explain the basics of community to a company that draws a distinction between where they are now and where they want to go, so these two really jumped out at me.

1. Communities are not teams
2. Communities are not websites

These two principles nicely articulate what a community is not and sometimes that’s more helpful and descriptive than trying to state exactly what they are.  Communities are NOT some nebulous team to manage or a website to maintain, communities are people.

But let’s think about where many companies are coming from.  Corporations have a clear chain of command, hierarchy and conformity are the norm and everything is organized by function and has an objective to be met.  Teams or websites fit this model of thinking pretty well which leads many managers to try to manage communities as if they were one or the other.  Concepts like “distributed decision making”, “earned leadership”, “reputation management”, and “merit based promotion” are foreign concepts that are not well understood and certainly not something they’d want to embrace in a hierarchical environment…. historically.  However, companies are beginning to appreciate the benefits of less structure and more communal efforts in productivity, worker morale and innovative thinking.

So what are communities …

Communities are not projects to be managed, but are people voluntarily coming together around a common interest or set of problems.

In essence communities are about …

1. People, people, people
2. Articulating a vision that others can embrace and commit to
3. Sharing information and ideas
4. Observing how things are done and helping out
5. Working together to fulfill the vision

So for all you managers out there trying to manage your way to a successful community, STOP.  Learn to manage by letting go and gently nudging here and there when things go astray but mostly just try to facilitate communication and stop trying to managing.

Email in most corporate environments has degenerated into a CYA system that sucks volumes of time and offers less and less value in the face of competition like IM or Facebook.  In the golden age of handwritten notes writers tended to craft very thoughtful correspondence and then it was only sent to one person.  Now in the age of Email Overload, my belief is that correspondence is less  personalized and well thought out and is driven primarily by the need to “just reply”.

In addition to the “craft” of writing dying, the other problem is the “Reply All” button.  Reply All seems to have taken over corporate email systems so that not only has the list of recipients increased in order to cover someone’s butt, but now everyone is replying to everyone else in a vicious cycle of unproductively.  Many people I know have even abandoned reviewing email they are CC’d on due to the volume of email they receive.  Their logic seems to be “if it’s not To: me then its not that important”.  And guess what?  They’re probably right.

In Glyn’s column he makes the case for relevance in determining what communication to read and I completely agree with this.  As the information available to us continues to increase our filters need to be improved.  Not only should our filters help us eliminate Junk but hopefully sometime soon they will help us find the Gold.  I posit that if you want to save email (and messaging in general) from this vicious cycle of unproductively we need to start by designing filters that help us sift through our information and find the most relevant information that can help us perform the task at hand.