Blog

National Healthcare Marketing Strategies Summit to Address Industry Challenges

Scott Paley — Tue, 24 Apr 2012 16:55:00 -0400

This coming weekend in sunny Orlando, Florida, while thousand of kids chase “Pirates of the Caribbean,” fly “Space Mountain,” and take pictures with Mickey Mouse, I’ll be sharing modern marketing strategies and best practices with executives from hospitals, medical centers, healthcare systems, and medical group practices.

The National Healthcare Marketing Strategies Summit starts this Sunday at the Orlando Ritz Carlton and Six Feet Up was kind enough to invite me to join with several members of their brain trust, speaking with attendees at the Six Feet Up exhibitor booth.

New Challenges in Healthcare

The healthcare industry is in a period of rapid disruption. Nobody can say with certainty what impact the Affordable Care Act (“ObamaCare”) will have, especially with key provisions being reviewed right now by the Supreme Court.

Additionally, healthcare providers are beginning to shift away from “fee-for-service” to a value-based system in an effort to contain out-of-control costs. Huge carrots and sticks have been put in place to strongly encourage the implementation of electronic medical record (EMR) systems, with the goals of reducing costs and increasing efficiencies.

How to Communicate?

In periods of transition, it is especially important for organizations to reevaluate their communications. Healthcare marketers wonder how they can deepen relationships with patients and practitioners, and how they can communicate more clearly, rapidly, and transparently, improving the overall patient experience.

The Role of Technology

Technology plays an enormous role in facilitating this transition. We’ll discuss with healthcare CMOs, Strategists, and Marketing Communication Executives, how web technology can disrupt healthcare as it did music, news, entertainment, finance, and so many other industries. We’ll demonstrate several technical platforms (such as open source technologies like the Plone Content Management System and the KARL Knowledge Management System) and how marketers can use these technologies to their advantage.

Several of the “Sixies” (that’s what we call Six Feet Up employees) will be available to show technology demonstrations at our conference booth, and for those that don’t have time during the conference, we’ll have an easy way of registering for a future demo.

The Conversation Continues

SharePoint is a widely used platform for collaboration, especially in Microsoft-centric environments. Microsoft says SharePoint “makes it easier for people to work together.” But, every time Six Feet Up attends a technology conference, a ton of people complain that it’s a bear – that it’s hard to work with and not user-friendly. They seem relieved and excited to learn that there are real alternatives.

To meet this strong demand, Six Feet Up will be offering a free webinar on May 16 at 2pm called “SharePoint Alternatives.” Six Feet Up CTO Calvin Hendryx-Parker will present several legitimate SharePoint replacements, including Plone, KARL, and Alfresco.

Healthcare marketers are particularly encouraged to attend the webinar, as the content will be especially relevant for them. Of course, we will be heavily promoting the webinar at the conference.

You can register for it here.

The Conference Goes Mobile

Finally, Six Feet Up did something super cool for the conference – they created the official conference mobile app!

Point your mobile browser to http://m.sixfeetup.com/hcms/ for the conference schedule, speaker information, online conversation, and more.

The Most Important Thing To Do When Starting With Plone

Elizabeth Stratton — Thu, 19 Apr 2012 06:35:00 -0400

Back in March of 2011, I had the opportunity to start working for Six Feet Up as a member of their Quality Assurance team. I had previous exposure to Plone years earlier creating an out-of-the-box site using standard Plone plug-ins, but not much exposure to Plone customizations.

My job is to test sites in various development stages for any issues that may cause a client's site to stop working as it was intended. At different phases I test for standard functionality, customized features, design and the intended user experience. Just like the project managers and developers, I must keep the entire project in mind while testing in order to foresee any possible hiccups that may arise.

"I was so focused on learning every step of the QA testing process that I almost missed one of the most important steps: learning Plone's default behavior."

Right away it seemed intimidating and perhaps I had bitten off more than I could chew. Six Feet Up's projects usually involve some rather sophisticated implementations and my first weeks were spent shadowing Six Feet Up's Lead QA. I could see that, if I did not think the whole testing process through, and did not test a feature, or forgot to test an attribute, I could miss even a small difference that could potentially cost more later down the road.

I was so focused on learning every step of the QA testing process that I almost missed one of the most important steps: learning Plone's default behavior. Just spending time exploring and clicking around Plone's features is invaluable and should be any Plone newbie's first steps toward better understanding what makes this product one of the best open source CMS' on the market.

Thankfully Six Feet Up has many individuals who are expert at customizing and deploying Plone sites, and I am glad they were patient with me while I learnt my way through Plone's UI.

It's been almost a year since I first started and I am now more familiar with what Plone can do to meet client needs. It's been a great journey, and I am eagerly looking forward to learning more and more about Plone's wide array of possibilities in the arena of enterprise content management.

4 Critical Mantras For Effective QA

Christine Shaw — Mon, 16 Apr 2012 06:30:00 -0400

If you would like to have a great career in QA, and be seen as a Super Hero in your development team, here are 4 critical mantras to keep in mind at all times:

1. Adopt a neutral, non-judgmental tone... no matter what!

Sometimes it can be tempting to quickly downgrade a developer's mental agility and furiously write something like:

"Feature was implemented completely wrong."
"Developer obviously didn't read the spec."

But how you "feel" about the bug and getting on the developer's bad side will reduce open communication with team members. Instead, bug reports should use neutral language and remain non-judgmental.

2. Be explicit and describe how the system should behave

Here's a common example: an issue ticket says "Header on page 1 and page 2 is blue." Developer responds by changing all other page headers to blue. But the tester had assumed the developer knew that they meant the header on page 1 and page 2 should be black, like all the other pages. Assumptions like this one cause unnecessary work for developers and can negatively affect a project's budget. Rather than describe a problem, be sure to explain how the system should behave.

3. Do NOT follow developers' test instructions

Developers will send you comments like this one: "Create 3 terms: apple, banana, mango. The drop-down should display the terms sorted alphabetically."

If you were to follow the developer's test plan to a T, the following issues may be missed:

Sort order could be defaulting to ascii value instead of alphabetical (found by adding terms with different capitalizations or numerical values, etc.)
Sort order could be defaulting to order the terms were created instead of alphabetical
Drop-down menu could not display entire text of much longer terms than "banana"
Drop-down menu could throw error when odd characters are included in labels (e.g. "apple & banana")

While it's useful to review developers' descriptions of how it "should" work, be sure to formulate your own ideas about how to test!

4. Spend your time where it matters most

Are those 2 pixels left of the column driving you nuts? Have you sent it back already, and now there are 3 pixels? And it comes back again, only this time there is 1 extra pixel?

Meanwhile, you've spent almost half an hour worrying to death about these 2 pixels while main functionalities of the site, such as an e-commerce cart, remain untested. This is obviously a pretty inefficient approach to testing.

Instead, try to organize your day so that mission critical or time sensitive issues are tested first. Some examples might include:

Very first releases of large features
Any complex logic situation
Features that would satisfy an entire Business Requirement in one shot

Git Credential Helpers

David Blewett — Wed, 11 Apr 2012 06:20:00 -0400

In the most recent major release of git (1.7.9.x), a new "credential API" was introduced. This allows you to store supplied HTTP credentials in a variety of containers (OS X's keychain, in-memory cache and plain-text flat file). This is a major step forward in usability for anyone cloning repositories over HTTP/HTTPS. Before, you either had to enter your username and password every time you interacted with the remote server or use the insecure method of embedding your password in plain-text in the ~/.netrc file.

The documentation for this new API can be obtained via git help credentials. By default, git comes with 2 methods of caching supplied HTTP/HTTPS credentials: an in-memory cache and a plain-text on-disk store. Probably the more interesting however, is the osxkeychain helper in contrib. It is available by default if you build git via MacPorts. This helper will store your username and password securely in OS X's keychain. In order to activate this helper for all repositories by default, do the following:

git config --global credential.helper osxkeychain

After the next interaction with a remote git repository over HTTP/HTTPS, git will store your supplied credentials in your login keychain. You can confirm by using the Keychain Access utility and searching for the domain name hosting the repository.

If you install git via MacPorts, you can ensure you have the helper installed by typing the following:

$ port installed | grep git
git-core @1.7.9.2_0+credential_osxkeychain+doc+pcre+python27 (active)

The credentials_osxkeychain variant confirms we have a functioning setup.

While not quite as exciting as keychain storage, the ability to cache credentials in memory can be extremely useful when operating on a remote server. This can be activated via:

git config --global credential.helper cache

The default is to cache values in memory for 15 minutes (see git help credential-cache for available options). After the next time you access a repository over HTTP/HTTPS, you should see a process similar to the following running:

davidb         44198   0.0  0.0  2438820   1164 s002  S     2:29PM   0:00.00 git-credential-cache--daemon /Users/davidb/.git-credential-cache/socket

If you a are a Plone developer using mr.developer with repositories hosted over HTTP or HTTPS, these new options will be an extremely welcome addition to your toolset.

Interested in more technical opinions and reviews? Sign up for our mailing list.

How to Dramatically Speed Up In-Browser Web Testing

Christine Shaw — Mon, 09 Apr 2012 06:30:00 -0400

Cross-browser testing can be time consuming when performed manually. Selenium Grid can distribute automated UI tests across multiple platforms, reducing test time overhead and providing quick feedback independent of infrastructure.

Quick Start Guide for Selenium Grid:

1. On the grid host machine and the remote machine or VM (which the browsers will run on):

install Java
download the Selenium standalone server

2. The host machine will distribute the requests to the remote machines. On the host, start the server with the command:

java -jar selenium-server-standalone-X.Y.Z.jar -role hub

where "X.Y.Z" is the version you downloaded.

You can view the console in your web browser by going to:

http://HOST.IP.ADDRESS:4444/grid/console

where "HOST.IP.ADDRESS" is the IP of the host machine.

3. Start the remote node on your remote machine or VM with the command:

java -jar selenium-server-standalone-X.Y.Z.jar -role node -port 5572 -hub http://HOST.IP.ADDRESS:5555/grid/register

where "X.Y.Z" is the version you downloaded, and "HOST.IP.ADDRESS" is the IP of the host machine which will distribute the requests.

4. Write your test script in the language of your choice. For example, in Python -- install the selenium package. To launch Firefox and load Google on the remote machine:

from selenium import webdriver

driver = webdriver.Remote("http://HOST.IP.ADDRESS:4444/wd/hub", webdriver.DesiredCapabilities.FIREFOX)
driver.get("http://www.google.com")
driver.quit()

For more information about, check out the Selenium Grid website.

Interested in getting more tips to make your development more efficient? Sign up for our mailing list...

PyCon 2012 Wrap Up

Calvin Hendryx-Parker — Wed, 21 Mar 2012 09:19:29 -0400

This was the 9th PyCon that Clayton and I have attended since the first one in 2003 where we were 2 of the 250 that were in attendance. This year was amazing and there were around 2200 people this time. The organizers deserve a huge pat on the back for a job well done and they set the stage perfectly for us all to learn and connect with the Python Community.

PyWeb Summit

This year we participated in the PyWeb Summit organized by Michael Ryabushkin and Chris McDonough. If the goal was to get us all in a room and start talking with one another, it worked, which was critical given the lack of conversation happening on the Web SIG mailing list. There was much discussion about deployment and packaging, but most suggestions seemed geared toward small site deployments with little additional needs.

The most interesting part of the day was probably the lightening talks and the "State-of multi talk". Each of these provided interesting windows into what was coming up or how things were going in the various projects. For instance, there appears to be work toward making all of the major web frameworks Python 3 compatible, but most of the folks in the room aren’t using Python 3 yet. Certain projects, such as CherryPy and Twisted, are at a point where they are very stable and considered complete. Other projects such as the Pylons Project are experiencing a surge in growth as they adopt new technology like the Pyramid web application framework.

PyCon Keynotes

As many have said already, any event that kicks off with dancing robots is an awesome sign of things to come during the conference. The keynote sessions were very enlightening and all very different from one another. Stormy’s talk about community was a great reinforcement of the things I have learned while participating in the Plone community.

Go view them at PyVideo.org where the Next Day Video team did an amazing job of getting them all online almost before we left the conference.

Tracks Galore

One of my favorite tracks this year was the maker track that was full of awesome talks about hacking Arduinos to control pyrotechnics, printing 3D models with MakerBots and even using Python and computer vision to track and shot squirrels in your backyard. Python people do the coolest stuff on earth.

If you were into the more serious topics, there was a great mix of advanced Python talks about web, data processing and scientific topics. In addition, this year also had some great talks that were only loosely Python-related, such as how to do better sketches and a historical look at asking for forgiveness vs. permission.

The most important track though, as usual, was the hallway track. The layout of the conference and the expo hall was highly conducive to this great form of catching up and meeting new folks. How else do you recruit people to participate in your next FedEx Day or find out cool tidbits of information such as the fact that Industrial Light and Magic uses Plone internally. People are truly what makes PyCon one of the best conferences to hit all year.

Ready, Set, Sprint

I didn’t get to stay for much of the sprints, but just the sight of an estimated 700 people working on Open Source is breathtaking and inspiring. This community is a model to be emulated. I was in the Pyramid room where they had to bring in additional tables just to handle all of the people who wanted to help with the project.

Looking forward to next year

I can’t wait to see everyone again next year and I’m sure I’ll run into some of you before then at Open Source Bridge or the Plone Conference.

A Solution to Fixed-Bid vs. Hourly Contracts (Part 3)

Gabrielle Hendryx-Parker — Tue, 20 Mar 2012 13:10:00 -0400

In my last post, I described why "Time and Materials" contracts ("T&M" in short) are the only sensible structure for sophisticated software development like we work on at Six Feet Up, but only in concert with a project management methodology that reduces risk for clients.

As I wrote, "The key to reducing the risk of time and materials is transparency and frequent check-ins... A successful engagement must transparently manage your risk, enabling you to see exactly how your dollars are being spent, and empowering you to make frequent, well-informed decisions that concern the budget and scope."

Our "Flex6" methodology does just that.

First, Traditional Project Management

Traditionally, your service provider spends a bunch of up-front time putting the project details on paper and getting client approval. Then development takes place. The provider tests and debugs and finally shows the project to you. With a little luck, the original estimate was accurate and the project, at this point, is right on budget and on time.

But...

What happens when you review the work and want changes? Certain features maybe didn't get implemented in quite the way you imagined. Remember, this is the first time you’re really getting a chance to play with the new system. We all know how hard it is to give feedback on something you haven't actually seen yet.

Inevitably, something unexpected comes up during that client review. Since it was, by definition, unexpected, it wasn’t budgeted for. Uh oh. Now there’s a problem. If you are to get what you want, the project is going over budget.

But now you’re angry. You think your service provider misinterpreted something you wanted. They think they built exactly what you asked for and show you the approved scope of work, proving they’re in the right.

But does that make any difference? What really matters is that even though the project is nearly done, and even if in the end the project is a big success, everybody is left with a bad taste. The relationship has been damaged.

A Better Way: Flex6

To better manage our client’s projects we have developed a methodology we call "Flex6." The key attributes of Flex6 are:

We build, test, and debug one component or milestone at a time, working on the most critical tasks first, and immediately have a client review before moving on.
During this review, we get our clients’ feedback on the work performed and discuss the budget. We know how much time was supposed to be put into the component. If we’re tracking too high or low, we can adjust much earlier in the process.
After each review, we tweak the reviewed component based on the feedback, and work on the next component. Then, we do another detailed feature and budget review.
Since we work on the most critical features first, if something needs to be cut from the scope in order to keep to a budget, it's the least important features that will be cut.
All throughout this process, our clients can fully control their budget allocation. There are no surprises.

While this process is still hourly, it meets all of the important criteria I mentioned in my last post:

Confidence: Set and manage your budget. Yes.
Transparency: Know how much money you’ve spent at all times. Yes.
Visibility: Know how much of the project is done, and how much is left to complete. Yes.
Understanding: Understand the impact of any desired scope changes (and allow you to make them in the first place). Yes.
Alignment: Make sure your service provider is properly incented. Yes.

Interested in discussing how our Flex 6 process can benefit your custom software development needs? Just contact us.

Also, be sure to sign up for our newsletter to read more interesting articles and blog posts related to sophisticated software development.

A Solution to Fixed-Bid vs. Hourly Contracts (Part 2)

Gabrielle Hendryx-Parker — Tue, 21 Feb 2012 09:30:00 -0500

A few weeks ago, I wrote about how hard it is to estimate creative projects including sophisticated software development like we work on here at Six Feet Up.

From that post:

"When every project has unique requirements, how can a precise estimate be developed? (It can't.) And how can any project move forward without a reliable budget estimate? (Again, it can't.)"

Given that a budget gets set based on a guesstimate that’s more likely to be wrong than right, what’s the best way to set up a contract?

What Makes a Good Contract?

A contract defines a structure for managing your project. A good structure provides:

Confidence: Set and manage your budget
Transparency: Know how much money you’ve spent at all times
Visibility: Know how much of the project is done, and how much is left to complete
Understanding: Understand the impact of any desired scope changes (and allow you to make them in the first place)
Alignment: Make sure your service provider is properly incented

Fixed-Price Contracts

While fixed price projects seem to provide you with confidence, reduced risk, and incentives for us service providers to get the work done faster, they just don’t get you the items above.

Our strategy and design partner Abstract Edge did a great job explaining why fixed-price contracts aren’t as wonderful as they seem.

The key takeaways are that fixed-price projects set the wrong incentives, tend to be overpriced, and are inefficient, unending and inflexible.

Hourly, But With a Cap

A better way to handle this might be to pay by the hour, but with a cap. This gives you more flexibility, but some protection if things get out of hand.

But there are hidden problems. First of all, the service provider is penalized for finishing the work ahead the schedule, which is the wrong financial incentive.

Second, if the project hits the cap, it becomes a fixed price project anyway, with all of the issues I described earlier.

Time and Materials

The traditional way to pay for professional services is “time and materials.” This simply means that you pay based on the amount of time it takes to complete the work, plus for the cost of any out-of-pocket items. We’re all used to paying contractors and lawyers this way.

The time increment can be hourly, daily, weekly, or even monthly. For companies like Six Feet Up, hourly works best because it creates more flexibility for our clients than larger time increments.

On the other hand, what if we completely underestimated the project scope? Isn’t it too risky to pay by the hour?

Not necessarily. It’s how nearly all of our clients do it, and we have a lot of happy clients.

The key to reducing the risk of time and materials is transparency and frequent check-ins.

Reducing Risk

A successful engagement must transparently manage your risk, enabling you to see exactly how your dollars are being spent, and empowering you to make frequent, well-informed decisions that concern the budget and scope.

Time and materials is the only billing method that can support confidence, transparency, visibility, understanding, and alignment, but only with strong and effective project management processes in place.

Our proven project management methodology, which we call “Flex 6,” is the key to a successful project outcome. Flex 6 aligns interests and minimizes risk. It provides transparency and allows flexibility. It’s relationship-building and hands-on.

How does it work?

Don’t miss part 3 where I describe how we manage risks inherent to software development….

Want to be notified when part 3 is ready? Sign up here...

Create Your Own Plone Content Types With Dexterity

thomas — Tue, 07 Feb 2012 06:30:00 -0500

Like other Content Management Systems (CMS), Plone allows users to easily create and manage online content through the web by leveraging content types such as pages, blog posts, news items, calendar events, comments, etc. Those content types are typically custom-developed by programmers and require a formal code release to add the new types to a website.

And now Plone goes even farther: the Dexterity add-on allows non technical content contributors to not only use pre-existing content types, but to also define and create their own content types through the web (see screenshot).

Using Legos as an analogy, this means users can do more than just create a structure based on a given number of basic bricks: they can also design and use their own custom bricks.

Dexterity is Plone 4 compatible and the Six Feet Up development team is using it on most of our projects. It has several advantages over the classic "Archetype" content types, but the main improvement lies in the ability users now have to create content types in a WYSIWYG fashion. Many of our clients appreciate the fact that they can create their own content types, or tweak them on their own without having to ask for a developer's help every time they want to add or arrange a simple field.

Dexterity is also very developer friendly. For example, it is easy for a developer to export the content types created by a content contributor via Dexterity and reintegrate them into the code for optimal site efficiency. This also makes the content types data-independent and easily accessible to other web development projects.

With Dexterity, Plone now closes the feature gap with other well-known open source CMSs such as Wordpress and Drupal, which already offer this ability.

A Solution to Fixed-Bid vs. Hourly Contracts (Part 1)

Gabrielle Hendryx-Parker — Tue, 31 Jan 2012 06:30:00 -0500

Right now, I’m waiting for Audi to give my car an oil change and fix a problem with the power steering. While the technician told me that it shouldn’t take more than two hours, we’re nearly at three (and counting.)

Of course, the moment I wrote that, the technician came over to explain the delay. Turns out they found a couple of unexpected (but legitimate) issues which they needed to fix. Things weren’t quite as simple as he originally assumed.

Pretty typical.

Which brings me to this. If an auto-mechanic can’t accurately estimate a quick and simple car fix, what hope do software developers have when building something new and complex, over the course of many months (or years,) that’s never been exactly done before?

Technology projects are notorious for cost overruns.

The Hubble Space Telescope, which has allowed us to look back in time nearly all the way to the big bang, was originally supposed to cost $400 million to build. Final construction costs actually came in at $2.5 billion.

Boston’s “Big Dig” and Denver’s International Airport were each supposed to cost $2.8 billion. They cost $14.6 billion and $4.8 billion respectively.

A study performed a few years back by the Standish Group discovered that 71% of IT projects were over budget with a total average overage of 43%.

Why does this happen? And what does a space telescope or a major construction project have to do with your website or intranet?

The answer is they are all creative exercises. They are unique. There isn’t another tunnel exactly like Boston’s in the entire world, and there isn’t another website exactly like yours. You can’t build your website on an assembly line, and if you could, you really wouldn’t want to.

Sure, it would be great if we could send a bunch of commodity-priced raw materials into an airport construction factory, click the “on” button, wait a predictable amount of time, and out comes your airport, ready for takeoffs, landings, and weather delays.

Predictable inputs. Predictable outputs. Ah….

But websites and intranets are more like art, music, and literature. I want to commission you to compose a 45-minute orchestral masterpiece for our symphony. How much time will that take you? Um…

"Websites and intranets are more like art, music, and literature..."

OK, not all web projects are complex. Some are simple and straightforward and can be easily developed by your nephew who learned some HTML as part of a school project. Those just aren’t the kinds of projects we work on.

Six Feet Up builds sophisticated websites, intranets, and extranets.

For example, we develop a lot of websites on Plone, an open source, Python-based content management system. Plone is perfectly suited for complex content management, customized content types, intricate workflows and permission structures, and integration with other discrete technology platforms (i.e. CRM systems like Salesforce, authentication systems like LDAP, etc.) With Plone, you can create and manage numerous sub-sites that inherit content and templates from a parent site. You can build a global website, managing content in dozens of different languages.

Plone is unbelievably powerful and flexible. It’s also quite user-friendly for content managers.

But, Plone development is not simple. For those with generic, simpler needs, a solution like WordPress may be more appropriate (and easier to estimate.)

So when it comes to budget estimates, where does this leave us? When every project has unique requirements, how can a precise estimate be developed? (It can’t.) And how can any project move forward without a reliable budget estimate? (Again, it can’t.)

What kind of payment structure can be created that’s fair for all parties?

"What kind of payment structure can be created that’s fair for all parties?"

We have an answer that’s worked extremely well for our clients. Our solution and process aligns interests and minimizes risk. It provides transparency and allows flexibility. It’s relationship-building and hands-on.

What is it?

Stay tuned for part 2 where I go over why "Time and Materials" contracts are the only sensible structure for sophisticated software development...

Want to be notified when similar blog posts get published? Sign up here….

Optimize Your Plone Development by Packing the ZODB

Clayton Parker — Fri, 27 Jan 2012 06:30:00 -0500

What does it mean to "pack" a database? In shortest form, it means to remove unused records in order to reduce the memory required to hold the database.

Think of it like this: each time you delete a page in your website, a copy of that page is kept in the database. These copies are kept in case you need to get it back later. Over time, as you create and delete content and make other changes in your website, the number of unused objects can grow and grow, expanding the memory needed to operate the website, and slowing down operations. When you pack the database, the system finds the unused objects and removes them. Performing this job regularly helps to keep the size of a database manageable.

Perform database packs regularly

What is the benefit of scheduling routine database packs? If the database is not being packed on a regular basis, the amount of resources and time to perform a database pack may increase exponentially. Making sure that the packs are happening on a scheduled basis will save time in the long run. These are tasks that can easily be added into your buildout and then released into a production environment.

As an example, we recently had a Plone site that was using RelStorage backed with MySQL that had not been packed in over a year. The size of the MySQL dump grew to nearly 8GB and took 45 minutes to complete. This means that any time a release was made, there would be 45 minutes of lead time just to make a backup of the data.

Having this large database does not only impact the ability to swiftly do a release. If a new bug is discovered that can only be re-produced on the production environment, you certainly don't want to be debugging it there. Instead, you will want to be able to quickly bring back the data to your testing instance, hence the benefit of keeping the size of the database to a manageable size.

Setting up the automatic pack

When using a ZEO server, either from plone.recipe.zeoserver or plone.recipe.zope2zeoserver, a zeopack script is automatically generated for you with all the necessary parameters to run the pack. This can simply be run from the command line:

$ cd path/to/buildout
$ bin/zeopack

Now your database is packed, that was easy! As programmers and systems administrators, we know that doing things manually will eventually fail. How do we automate this process? Simple, we add a cron job to take care of the work for us. Here is an example configuration that gets everything set up for us:

[buildout]
parts = instance zeoserver cron-pack
extends = http://dist.plone.org/release/4.1.3/versions.cfg

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
http-address = 8080
zeo-address = 8100
zeo-client = True
# Set the shared blob option so blobs work with zeoserver
shared-blob = on
blob-storage = ${buildout:directory}/var/blobstorage
eggs =
    Pillow
    Plone

[zeoserver]
recipe = plone.recipe.zeoserver
blob-storage = ${instance:blob-storage}
zeo-address = ${instance:zeo-address}
# keep history for 7 days instead of the default 1
pack-days = 7

[cron-pack]
recipe = z3c.recipe.usercrontab
times = @weekly
command = ${buildout:bin-directory}/zeopack

After running this buildout, there will be a cron job added to the cron of the user that ran the buildout. This job will run weekly and pack the database, leaving 7 days of history.

RelStorage

Now for a more complex scenario using RelStorage. The zeopack script will no longer work, but fear not, RelStorage comes with a script called zodbpack that can do the job.

First some setup to make the generation of the conf file work:

$ cd path/to/buidout
$ mkdir templates
$ mkdir etc
$ touch templates/zodbpack.conf.tmpl

This sets up a directory for our zodbpack.conf template, and an output directory named etc. In the zodbpack.conf.tmpl, place the following code:

<relstorage>
  <mysql>
    host ${settings:mysql-host}
    db ${settings:mysql-db}
    user ${settings:mysql-user}
    passwd ${settings:mysql-passwd}
  </mysql>
</relstorage>

Now here is our example buildout configuration that sets up Plone to use RelStorage with MySQL:

[buildout]
parts = instance relstorage zodbpack-conf cron-pack
extends = http://dist.plone.org/release/4.1.3/versions.cfg

[settings]
# settings for RelStorage connection
mysql-host = localhost
mysql-db = mydbname
mysql-user = root
mysql-passwd = 
# options for the cron job
pack-days = 7

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
http-address = 8080
eggs =
    Pillow
    Plone
    RelStorage
    MySQL-python
rel-storage =
    type mysql
    host ${settings:mysql-host}
    db ${settings:mysql-db}
    user ${settings:mysql-user}
    passwd ${settings:mysql-passwd}
    blob-dir ${buildout:directory}/var/blobstorage

# Generate the RelStorage scripts
[relstorage]
recipe = zc.recipe.egg
eggs =
    ${instance:eggs}
    RelStorage
    MySQL-python

[zodbpack-conf]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/zodbpack.conf.tmpl
output = ${buildout:directory}/etc/zodbpack.conf

[cron-pack]
recipe = z3c.recipe.usercrontab
times = @weekly
command = ${buildout:bin-directory}/zodbpack -d ${settings:pack-days} ${zodbpack-conf:output}

In this example, we are generating a conf file for the zodbpack script to use with the [zodbpack-conf] part. Since the RelStorage information will be used in two places, and might be different on each deployment platform, there is a [settings] section that both the [instance] and [zodbpack-conf] parts take advantage of.

Once this buildout has run, it will be set up similar to our conventional buildout. The cron job will pack the RelStorage database once a week, keeping 7 days of history.

Conclusion

Packing your Plone site's database on a regular basis is as simple as adding some configuration to buildout. There is really no reason you shouldn't be keeping up on this maintenance task with your Plone sites, especially when you run complex websites or intranets. It will save you time during your development and release cycles by making sure the database is at its leanest.

Set up IPython for Plone Development

Clayton Parker — Thu, 12 Jan 2012 10:45:00 -0500

IPython is a powerful interactive Python shell that can be used with Zope to aid in debugging issues in your Plone development activities. Syntax highlighting, tab completion and code introspection are just a few reasons to use it.

Think of the Zope-enabled IPython shell as bin/instance debug on steroids. When you start up the default Zope instance debugger, you are only given an app variable to access the current Zope instance. The IPython Zope profile enhances this with some useful defaults. It sets the variable portal to the first Plone site that it finds, sets up a dummy request on it and then does a setSite to make the component architecture work properly. There is also a utils object that is set up to allow you to sync the database, commit your changes, switch users and a host of other things. This gives you a series of effective tools to improve your Plone development practices.

A while back, Kees Hink wrote up a blog post about using IPython with the powerful content management system Plone 4. Since then, a newer version of IPython has come out and is no longer compatible with Python 2.4. This post will help you get it working with Python 2.4 and IPython 0.10 (for Plone sites on version 3.x or earlier), then Python 2.6 and IPython 0.11 or 0.12 (for Plone sites running Plone 4+).

Add Zope enabled IPython to buildout

We will assume that your Zope instance is created with a part named [instance] and, in the case of Plone 3, Zope is installed with a part called [zope2]. Here is what the Zope enabled IPython part looks like (uncomment the Plone 3 lines if needed).

[buildout]
parts =
# NOTE: You will have a zope2 part if using Plone 3
#    zope2
    instance
    ...
    ipzope
versions = version

[versions]
...
# NOTE: Use IPython 0.10 for Plone 3
#ipython = 0.10.2
ipython = 0.12

[ipzope]
recipe = zc.recipe.egg
eggs = ipython ${instance:eggs}
initialization =
    import sys, os
    # NOTE: Include this line for Plone 3
    #os.environ["SOFTWARE_HOME"] = "${instance:zope2-location}/lib/python"
    os.environ["INSTANCE_HOME"] = "${instance:location}"
    sys.argv[1:1] = "--profile zope2".split()
# NOTE: Include this line for Plone 3
#extra-paths = ${instance:zope2-location}/lib/python
scripts = ipython=ipzope

Notice that the --profile option is new, they removed the -p option in the latest IPython. The --profile still works with IPython 0.10, so we can keep that option for both versions of our part. We are also calling the profile zope2 instead of the normal zope. This is because IPython 0.10 was bundled with the zope profile, so we won't be able to use our new and improved profile unless we rename it.

Set up the zope2 IPython profile

Now that we have this added to our buildout, we need to get IPython set up with the profile. This is where things get difficult. The profile format has changed from 0.10 to 0.12, this means we should make a copy before we do anything else. This directory will only be present if you have already used IPython in the past.

$ cd
$ cp -r .ipython .ipython_0.10

If you don't have an IPython directory, running ipython or bin/ipzope will create one for you. The 0.10 version will tell you that it is creating it, the 0.12 version just silently does it. Let's go ahead and create the config skeleton.

$ cd path/to/buildout
$ bin/ipzope

Now let's add in the Zope profile. I have merged the Plone 4 branch that Kees created and fixed up a few other things, so we can now use the trunk. Let's check that out for use later.

$ cd
$ svn co http://svn.plone.org/svn/collective/dotipython/trunk/ .dotipython

Now let's symlink into the proper places. The 0.10 profile expects this to be a file named ipy_profile_<name>.py, where <name> is the profile name.

$ cd ~/.ipython
$ ln -s ~/.dotipython/ipy_profile_zope.py ipy_profile_zope2.py

Notice that we have renamed it to zope2 here to avoid the clash with the profile included with IPython.

Now let's add a 0.12 friendly version. The latest version expects a profile to be a directory in the format profile_<name>. The actual Python file will live in a startup sub-folder of the profile.

$ cd ~/.ipython
$ mkdir -p profile_zope2/startup
$ cd profile_zope2/startup
$ ln -s ~/.dotipython/ipy_profile_zope.py .

In this case, it doesn't matter what the name of the Python file is inside the startup directory. IPython will just read each file in alphabetically.

Now we can start up ipzope and we will have all of the Zope features that we are accustomed to.

$ cd path/to/buildout
$ bin/ipzope

Just remember that you will have to change the [ipzope] part slightly and require ipython = 0.10 for use on Plone 3.

Working with 0.10 and 0.11+

The last nagging issue that you will run into is that when you run a IPython 0.12 shell, it will automatically upgrade your ~/.ipython directory. If you want the prompt to work correctly with 0.10, you will have to have a copy of your ipythonrc and ipy_user_conf.py files handy to put back in place. We can use the copy we made earlier.

$ cp ~/.ipython_10/ipythonrc ~/.ipython/.
$ cp ~/.ipython_10/ipy_user_conf.py ~/.ipython/.

Now you can use the 0.10 version properly again. If you don't have a copy of a 0.10 ~/.ipython, you can run the 0.10 version of ipython to generate a new ~/.ipython directory (you will have to move the current one out of the way first).

Conclusion

If you are doing Plone development without the use of a good interactive debugger, you are missing out because you can't run code interactively and figure out an issue efficiently. Try setting up IPython or try out bpython for an alternate option. This will take your Plone development to the next level by getting you closer to the code and making you more productive.

UPDATE: To use the 0.10 version after having used 0.12, you need the ipy_user_conf.py also. Instructions above updated.

Why PEP8 Makes your Plone Development Easier

Calvin Hendryx-Parker — Mon, 09 Jan 2012 09:35:00 -0500

Hardly any software is maintained by the original author for its whole life and some claim that 80% of the lifetime cost of a piece of software comes from maintaining that code.

Plone, as an open source software, is developed and maintained by thousands of developers from around the world. Therefore our Plone development team gets regularly tapped for help to make a Plone site faster or add new functionalities to it.

Picking up code that is badly written is like picking up a book in another language. Imagine reading your favorite book in English if the words were written from right to left. Scanning is hard. You have to read every single word. Understanding the story plot (i.e. code) is a much slower process and much less enjoyable experience.

Code validation (i.e. testing) is also a necessary activity that sends developers on a hunt for what might be causing a specific bug. If the code is clean, finding and resolving the error is much faster.

In short: bad code is both evil and expensive to both a development team and their client.

Code Standards To The Rescue

Fortunately, standards are here to prevent issues that could arise from bad code. Code standards define code layout (indentation, spacing, blank lines, line length, etc.), naming conventions, comment usage and code structure.

Senior Plone Developer David Blewett explains: "Code standards are all about making code look consistent. When people from several projects all use the same guidelines, you can scan a given piece of code for a section that you are looking for much more easily." Enhanced code readability allows developers to find errors more easily and more quickly, and collaborate with each other more effectively. This is crucial for Six Feet Up as we closely collaborate with our clients' Plone developers and other Plone Development partners.

Code standards also make finding similar chunks of code across a large code base much easier. This saves our Plone Development team valuable time when working on large development projects. Not to mention the fact that educated clients often require their enterprise software development vendors to follow best practices...

Lastly, if you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create. This speaks to the quality of your work and the reliability of your brand.

Why Use PEP8 In Your Plone Development

PEP8 is a coding convention for Python code that was established in 2001. What we like about PEP8 is that it was written at the language level. PEP8 doesn't explicitly mandate each detail of how to format code. It provides the basis for the big choices (tabs vs. spaces for indenting, indent width, line length, etc). As long as code follows those and is internally consistent, it's easy to read.

Just for fun, here are our Plone development team's top two PEP8 pet peeves: 1) lines of code should be less than 79 character long so as to have 3 files open side by side on your screen, and 2) you should organize import statements by external package to make dependencies explicit.

How To Start Incorporating PEP8 In Your Daily Plone Development Routine

Read the style guide for Python code written by Guido van Rossum and Barry Warsaw. Then watch the talk that Clayton Parker, Senior Developer at Six Feet Up, gave at PyOhio entitled Code with Style (slides are up on Slideshare).

Also read the following article about having a concept of "bad" and "well" formatted code: http://www.joelonsoftware.com/articles/Wrong.html

Finally, leverage a command-line script that you can run to check existing code: PEP8 is released on PyPI so you can install it using your favorite packaging tool (easy_install, pip, buildout).

And make sure to train your Plone development team on PEP8 techniques on a regular basis. It usually is a great idea to appoint one of your programmers as your PEP8 champion.

5 Ways to Improve Your Blogging Effectiveness

Gabrielle Hendryx-Parker — Fri, 09 Dec 2011 06:30:00 -0500

Here are five tips to help you get the most out of your blogging efforts:

1. Understand why blogging is key...

... This will motivate you to blog more. Most people who don't blog cite lack of time as a major excuse. But blogs have a big impact on traffic and online visibility. First off, blog posts influence SEO because the frequency of content changes is important to search engines. Then they promote the fact that your organization is keeping up with new technologies and is using it to reach out and communicate with its audiences (communication is more key than ever). Finally, blogs have a training benefit because they force marketers to think harder about positioning and key messages.

2. Target the right frequency and length

Many people also imagine they need to blog every day and output a full-blown white paper each time. This just isn't true. Blogging twice a week and targeting about 300-400 words per blog is adequate. This should relieve some pressure and make the task easier to fit in a calendar.

3. Set up individual blogs

Mid to large companies wonder whether to set up a corporate blog or rely on individual blogs. Yet most customers are yearning for a one-on-one discussion with an individual, not a corporation. We, at Six Feet Up, set up our company blog to be a collection of individual voices and we think this structure resonates much better than a soul-less corporate message. Which is why we also ask our team members to redistribute our blog posts. This is also the strategy embraced by one of our clients: the Indiana Historical Society.

4. Turn to your clients for inspiration

Marketers sometimes wonder what to blog about. An endless supply list is simply your clients' questions. Just identify the most comment topics and address them in your blog posts. Another great way to leverage blog posts is to use them as a follow-up to an event where you presented. Simply prompt your audience to opt-in a mailing list by offering "6 Tips You May Have Missed From Today's Presentation Emailed to You Tomorrow. Just Opt In Here".

5. Include a call-to-action

Remember to use a very effective technique to boost your blog's effectiveness: always end your post with a powerful call-to-action. State who you are, what benefits your clients enjoy by working with you, and what your readers can easily do to get something for free. The key is to make it easy for people to connect with you easily and passively.

Gabrielle Hendryx-Parker is the CEO and co-founder of Six Feet Up, a company that helps universities, non-profits and life sciences organizations implement sophisticated websites. To see how we helped Indiana Historical Society roll-out their blog, please visit http://bit.ly/sCkxUS

Six Feet Up’s Take-Aways from the 2011 Plone Conference

Calvin Hendryx-Parker — Thu, 08 Dec 2011 07:00:00 -0500

Six Feet Up attended the Plone Conference in force this year with 8 Sixies traveling to San Francisco, and 4 of them presenting. Here’s a summary of what we learned and why we think it is important if you are using or considering using the open source CMS Plone.

The Future of Plone

Some of our favorite talks during the conference were those related to up-and-coming tools and technologies. Plone is heading toward separating authoring tools from template HTML with CMSUI, which means that the standard UI elements are moved out of the main template and the main page markup, and into an isolated iframe so they don’t interact with the overall theme. This will result in faster performance for anonymous users and will make it easier to theme Plone sites. Upgrading to newer versions and integrating new add-on functionalities will also get simplified as a result of that change. And it will be possible to offer multiple default themes to choose from out-of-the box.

Last, the community is finally hearing content editors’ cries for a better visual editor, which is prompting a group of developers to evaluate and re-evaluate options available out there, including CKEditor, Aloha, and TinyMCE. Stay tuned for the WYSIWIG Battle!

Integration

David Glick (Groundwire) presented an interesting Plone-Salesforce integration project for Net Impact leveraging Dexterity, a Plone add-on that makes it possible to create new content types through the web. Using the Dexterity-based membrane user code, dexterity.membrane, Groundwire rolled out two-way content syndication so that member profiles were kept in sync in both Plone and Salesforce.com.

David also showcased a donation system implementation using a custom GetPaid wrapper. The small library allowed them to use GetPaid without the heavy front-end code that comes with the Plone e-commerce product.

Geir Baekholt (Jarn) presented a fantastic integration project between XMPP (Jabber) and Plone called jarn.xmpp. He demoed realtime collaborative editing a la Etherpad inside a Plone site. This will definitely be a winning feature for Plone-based intranets.

Theming

Six Feet Up Senior Template Developer Chrissy Wainwright spent her first two full days in San Francisco training a group of 13 people on how to theme Plone.

The hot topic always seemed to be Diazo and Chrissy was asked a lot of questions about her opinions and level of difficulty in presenting it as a training topic. While currently we aren’t using Diazo much ourselves, it is exciting to see all the plans in the making for plone.app.theming and how it will be used.

Geir Baekholt also showed a demo of CMSUI (see “The Future of Plone above”), the new slick editing interface for Plone with Google-style editing tools that are sure to delight content contributors.

Rob Porter (Weblion) presented a talk on “Making Plone Mobile using Responsive Web Design” and demoed examples of mobile pages where page elements automatically resize and move around to adapt to new screen constraints in order to answer the challenges posed by a plethora of mobile devices. His tip: design the user experience with a small screen size first, and then expand. Rob also stressed on the fact many organizations are currently rolling out mobile versions of their sites.

We also learned a bit from Steve McMahon’s (Reid-McMahon) Javascript talk in relation to HTML5 and Plone 4 overlays.

Intranets

Six Feet Up CEO Gabrielle Hendryx-Parker spoke with many Plone company owners and several of them are rolling out Plone-based intranets that are now more than just collaboration platforms. In addition to wiki pages, blog posts and file sharing, new intranets also include custom tools to address specific business needs. Interestingly, many of those projects are about moving legacy intranets out of Microsoft SharePoint. And more and more Plone consultants are investigating the open source Knowledge Management System, KARL, as a platform for those intranet projects, as Six Feet Up started doing over a year ago.

Related Technologies

This year at the Plone Conference there was a well attended related technologies track. There were a lot of talks on technologies that compliment Plone such as Solr, WSGI, git and Pyramid. Six Feet Up Senior Developer Clayton Parker gave a well-received talk about how to configure Solr to address specific customer’s needs. There was a lot of interest in these new technologies and how they relate to the Plone community.

Hosting

The main focus of the conference was on developement, yet there were a few talks about the hosting aspects of Plone. One exceptional talk was given by Adam Terry and the PretaWeb Group about their development of a high availability, high traffic site in Australia designed to deliver tsunami warnings and information. Their talk covered both the use of geographically dispersed hosting centers and content delivery networks to maintain a high level of service in the event of a natural disaster. Projects like these showcase the capabilities of Plone and the maturity of the platform.

Last Word

Overall, the conference was very well attended, with close to 60% of the participants coming from another country, and 50% new-comers, which are signs of a healthy and growing community. We are very excited about the direction Plone is taking and we look forward to the great improvements that are coming, especially in the area of usability.

As is the case every year, the Plone Foundation met and elected a new board. This year, our very own Director of Business Development, Carol Ganz, was selected to serve with a group of 7 talented individuals from around the world.

San Francisco is still as energizing as it ever was, and shows no sign of ever slowing down.