Blog

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.

Want to be notified when part 2 is ready? 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.

Six Feet Up's Fifth FedEx Day Yields 13 Successful Projects

amandak — Thu, 10 Nov 2011 10:15:00 -0500

What is FedEx Day

The idea for FedEx Day comes from the book Drive, by Daniel Pink, which looks at what truly motivates us. A FedEx Day allows team members to select a project of their choice that they can deliver overnight. Often it is a project that has been pushed to the backburner repeatedly or it is something that adds value but is not necessary for the daily function of the office. The main requirement is that it must benefit the company.

How It Works

We usually suspend regular activities from 3pm on Thursday to 4pm on Friday, allowing individuals and small teams to concentrate their efforts on their FedEx Day projects. All meals are provided, and the office is open overnight. On Friday afternoon, we gather to share our accomplishments, and we vote on the 3 best projects.

This 5th FedEx Day, 13 projects were delivered in a 24 hour period!

Team Alphabet

Michelle created a project management training guide to ease new account managers into their role at Six Feet Up. This training guide will assist new account managers with learning the "Flex6" project management process within the company. Michelle included a project simulation with action items to provide hands-on training while explaining each process.

Team FileOrganizerPro

Jen worked on organizing the accounting department files, many of which were the the same types of documents but were located in several different places. By organizing, labeling and filing, work is completed on time, bills are paid on time and the possibility of paying for something twice is eliminated. Having an organized space will eliminate clutter and make searching much more efficient

Team Forecast

Lauren worked on creating enhanced internal reporting to support strategic decision making. By using available data from various tools at Six Feet Up, Lauren created new templates for reporting and communicating our quarterly sales forecast and resource demand forecast. This will enable the team to have the necessary data needed to support mission critical decisions in an efficient and effective manner.

Team GetDown/Automate

Calvin, Chrissy and Thomas worked together to build a web application that will assist the Project Managers in generating proposals and dynamic wireframes. Together, these apps create a product called PMPanel, aka "PiMP".

The Getdown section of the PMPanel offers a drag and drop Ajax interface to create and edit proposals and convert them from a convenient, pre-written, version-controlled markdown form, to a ready-to-be-sent PDF. The Automate section allows for one click merging of Trac estimates with Omnigraffle wireframe files.

Team Git

David worked to centralize a Git server setup to be the canonical point for pushing changes to and pulling updates from, for internal projects. Progress was made towards hooking authorization and access control into the internal LDAP server and the steps needed to setup the web front end were documented.

Team HotSpot

Kyle created a concept design for an outdoor courtyard to be utilized by employees and neighbors of Six Feet Up during lunch and business hours. The overall intent for the design was to create a tranquil environment for potential users that could remain functional for day to day use and inviting during all seasons.

The project site is located immediately behind the Six Feet Up building and adjacent to the alley. Access to the courtyard is provided by an additional run of stairs attached to the existing metal staircase, a gated entry off the alley, and an emergency exit for the first floor tenants. The courtyard design includes a lounge area complete with tables and chairs, an outdoor kitchen, and a fireplace with integrated water fountains as a focal feature. In addition, the courtyard is spanned by a removable fabric shade for protection from the weather and is completely enclosed by a brick wall or optional planted border, for privacy and security.
Kyle received a silver award for his excellent work. Congrats!

Team Marketing

Gabrielle, Carol, Amanda, Mohamed and Mark were very productive as they developed a plan to increase the company's web traffic, finalized the content of several case studies, crafted a new slick aimed at our Life Sciences clients and designed a new banner display for Six Feet Up's booth at the upcoming Healthcare Internet Conference. Team Marketing also worked on internal marketing projects and researched schwag ideas.
Team Marketing finished third. Kudos to all the great deliverables produced in such a short time!

Team Skeletor

Cris managed to push out a new release of Zopeskel, 2.21.2, with improvements from Mikko Ohtamaa and Alex Clark. He also released alpha versions of templer.zope and templer.plone, a new alpha version of templer.buildout and a new beta of templer.core. Cris also released a brand-new 3.0 alpha version of ZopeSkel built on the new templer functionality. Six new releases in 24 hours! Wheee!

Team Skeltron

Clayton worked on updating the internal paster templates that were still based on ZopeSkel 2.14 (almost 2 years old). Our sixieskel code fell behind after the great work that was done at the BBQ sprint. We are now basing our templates off of the new templer.core package, and have taken the same approach to splitting up our templates. The results of this work can be seen up on GitHub.

Team Timber

Steve and Chad worked on setting up a new centralized log server, with an eye toward systematic real-time log watching. Syslog-ng OSE was deployed to a new server, along with Simple Event Correlator (SEC). SEC provides the ability to filter log messages in real-time, as well as correlate log events, and generate notifications (e.g., email) for certain events. Basic log filtering rules (with notifications) were implemented as a proof of concept. This system will be evaluated for future use on all SixFeetUp infrastructure.

Team Trac Dashboard

Ron, Christine and Lucie made improvements to Trac (Six Feet Up's ticket and wiki system). These modifications will assist our scheduler and provide more information at a glance for account managers. A plugin was added to allow totals on columns displaying hours estimated, hours spent and hours remaining on the ticket query view. A new field was added to tickets so links to wireframes can be linked to easily. Additionally, columns were added on the table display of child tickets within the parent ticket view.

Team Watchful Eye

Luke and Lars worked to improve our internal network monitoring processes by deploying OpsView, a best of breed network monitoring system. This will replace the Zenoss monitor we have run for the last four years. Also deployed alongside OpsView is a StatusNet micro-blogging server, which in conjunction with OpsView, is being used to provide insight for account managers to keep a finger on the pulse of their customer's servers.
Team Watchful Eye received a Gold Award for their work. Congrats!

Team Voting Machine

Though not an official FedEx Day team or project, Clayton and Chrissy worked on a Pyramid-based web application that allowed the team to vote on the FedEx Day projects. This replaced our normal process of using SurveyMonkey. The benefit of creating a custom web app is to make viewing the voting results instant, instead of having to compile the scores while we all waited. The product is in beta form and Clayton has more plans for functionality, but the code is available on GitHub.

The next Six Feet Up FedEx Day will be held at the beginning of January. Six Feet Up invites other local businesses to join in the event to work on long-term strategic projects and increase employees satisfaction through independence and ownership.

What Catering Can Teach Web Project Decision Makers

Carol Ganz — Tue, 08 Nov 2011 13:12:54 -0500

It's Wednesday, and I just added a monkey to the menagerie living on my back. I have volunteered to help with the catering for the upcoming Plone Conference 2011. The event is in a mere 2 weeks and I'd better get hustling.

Instead of playing the game of negotiating prices down from their official menu, I have decided to follow a strategy that has always worked for me: Respectful Purchasing. I called the catering company of choice and just laid it all out for them to see: my budget, my requirements, my constraints, my deadlines. I didn't hold back. Then I hung up and waited for them to come back to me. This strategy paid off nicely and I was amazed: I got everything I wanted, and some, for the budget I had.

Back to the office, it dawns on me that Respectful Purchasing also works in our web development industry as this is at the foundation of most of my successful client relationships. Here are the 3 major points of Respectful Purchasing:

1 - Work with your vendor. Ask for everything you want but expect to compromise. Give a high level overview of your needs and let the experts provide recommendations. They have done it more than once. Give your vendor time to research options that could work for you. In my experience, vendors are always trying to please their clients and I am often surprised with my vendors' generosity. In this specific catering case, I would never have been able to afford the vendor's official service prices, but they were able and willing to work with my budget. Respect goes a long way.

2 - Be honest about your budget. Don't set your vendor up for failure. Too often clients won't tell me what their budget is. As a result, we all waste time with unrealistic expectations of what will fit in the budget. Instead, if the budget is too small, I will point the client to other vendors and/or other technologies and send them off their way without any time waste so they can make their deadlines. Honesty is the best policy.

3 - Be realistic in your expectations. You can't get filet mignon for $10 per person. But you could get sirloin tips. It's still steak, just in a different shape. Or can you compromise and trade a sit-down dinner for a buffet? In our industry, that means focusing on your project's goals and leaving the implementation details up to us. Don't insist on a specific add-on when we may have already done something similar using a different product. Let us make recommendations regarding the user interface as we may be able to save costs by simplifying a few elements.

Respectful Purchasing does work, whether in catering or web development. I dare you to try it. Just give me a call!

Why Learning Traditional Plone Theming is Important

Chrissy Wainwright — Fri, 30 Sep 2011 17:05:00 -0400

There has been a lot of excitement in the Plone community lately about plone.app.theming - which provides a way to theme a Plone site without having to learn a lot about Plone itself. It uses Diazo technology, which allows you to grab dynamic elements from Plone, and display them from a static HTML page. While this is the new thing that everyone is jumping to, that doesn't mean that traditional theming becomes obsolete.

I am a big proponent of traditional Plone theming. This involves overriding Plone templates and using Plone technologies like TAL and viewlets for building a theme. So far in my examination of plone.app.theming, I'm finding that many traditional theming methods are still important for creating themes that maintain full control over the display of Plone elements and content. I believe that if you plan on doing a lot of work in Plone, you should learn traditional theming methods.

Why traditional theming is important:

It helps you to understand the inner-workings of Plone. This can be important if you plan on doing more than just theming.
If you have just a small change that needs to be made in a template (such as newsitem_view), it can be a lot easier to throw that template into skins with your change than to write up the rules with your customization.
Learning TAL for displaying and modifying Plone content is very useful.
Generic Setup is recommended for use in plone.app.theming for controlling CSS and JS files through the registries.

Why you shouldn't jump into plone.app.theming just yet:

plone.app.theming is still a new technology in testing. Some sites are already using it, but I recommend waiting until it has been finalized and more documentation is available. There are a lot of planned features that have not yet been developed. (Though I know the developers would also appreciate it if you could test the product and provide feedback.)
At this point, Diazo templates and rules are not editable within the site. This is a feature currently in the works (and is looking great).
If building a Diazo theme from scratch, it can be easy to accidentally leave out some of the important Plone elements. Another feature being developed is a base theme that would give you a solid starting point.

Personally, I'm not convinced that plone.app.theming is the way for me to go in the themes I create from scratch, but I can see how it could be a very helpful tool, particularly with the current development being done on it. I just want to stress the importance of learning traditional theming methods, since they remain relevant.

In my Plone Theming Training at the Plone Conference next month, I will be focusing on traditional theming methods, but I will also cover creating a theme with plone.app.theming. There is still space available in the class if you want to learn how to theme Plone.

There will also be some Diazo talks at conference for those wanting to take that theming path.

What kind of experience have you had with plone.app.theming, and do you think traditional methods are still relevant?

Automating Plone site creation with collective.recipe.plonesite

Clayton Parker — Wed, 14 Sep 2011 11:06:12 -0400

Back in May, I gave a talk at Plone Symposium East about migrating from Drupal to Plone with Transmogrifier. Part of my presentation involved showing the power of collective.recipe.plonesite in combination with zc.buildout. During the talk, when I asked who had heard about this recipe, only a couple of people raised their hands. I then promised to write this blog post in order to raise awareness of the recipe and how it can help you.

The Plone site recipe makes it possible to automate the creation and maintenance of a Plone site via zc.buildout. The main goal of the recipe is allow for a Plone site to be created during a buildout run. When working on a project with a large group of people, it is important to make sure that everyone is working from the same basis. Buildout helps to do this by installing various additions and pinning versions, but there was no way to make sure the Plone site was always set up the same way. At Six Feet Up, this would lead to a lengthy "getting started" page being created on the project wiki.

Creating a Plone site

Automating the creation of the Plone site is as easy as adding a part to the buildout configuration. Here is an example of the simplest possible configuration.

[buildout]
parts = instance plonesite
extends = http://dist.plone.org/release/4.0.7/versions.cfg

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs = Plone

[plonesite]
recipe = collective.recipe.plonesite
site-id = test
instance = instance

This configuration consists of only two parts, instance and plonesite. The instance part sets up the Zope instance and downloads all the necessary packages to run Plone.

The plonesite part gives buildout the information it needs to create the Plone site. The site-id will be used as the id for the Plone site object that will be created. The instance option tells buildout what Zope instance will be used to run the script that creates the Plone site.

Running the buildout will now result in a Plone site being created.

$ python2.6 bootstrap.py
$ bin/buildout
Installing instance.
Installing plonesite.
Retrieved the admin user
Added Plone Site
Quick installing: []
Running profiles: []
Finished

Once that has completed, the instance can be started up.

$ bin/instance fg
2011-07-07 13:05:17 INFO ZServer HTTP server started at Thu Jul  7 13:05:17 2011
    Hostname: 0.0.0.0
    Port: 8080
...
2011-07-07 13:05:26 INFO Zope Ready to handle requests

To verify that the Plone instance has been created, open the site up in the browser by going to http://localhost:8080/test, you should see a blank Plone site which looks like this:

Installing Products and Profiles

The Plone site recipe also has the ability to quick install products and run GenericSetup profiles. This allows each developer to start with the exact same setup, since you know what was installed when the site was created.

The options provide two points where you can run your install code. The first is called initial. These options will only run after the initial creation of the site. This is useful for one time set up code that should only run after the site has been created.

The second install point runs every time once the site has been loaded. This allows for the ability to run the profiles and keep the site up-to-date. No longer will you have to release your code, then login to the site and have to remember what steps to take after that. The Plone site recipe can handle all this for you by relying on GenericSetup profiles to handle the heavy lifting.

Here is an example of using a fictional product named my.policy. In this policy package we have two profiles defined, my.policy:initial and my.policy:default. Here is how these would be added to the Plone site part:

[plonesite]
recipe = collective.recipe.plonesite
site-id = test
instance = instance
profiles-initial = my.policy:initial
profiles = my.policy:default

Following normal buildout conventions, you can add as many profiles as you like by adding the one per line or separated by spaces. At Six Feet Up, we typically only have the policy package listed here, the rest of the dependencies are handled via GenericSetup's metadata.xml.

Command Line Helpers

There are two helpful command line tips which make using the Plone site recipe even better.

The first is the ability to easily create a fresh build of a project that is under heavy development. In the early stages of development, there are times when your current instance may become unusable, or you need to run the latest profile code against a clean instance. This is where the site-replace option comes in handy. This option tells the Plone site recipe to delete the Plone site referred to by the site-id option. Here is how to do this from the command line:

$ bin/buildout plonesite:site-replace=True
Retrieved the admin user
Removed existing Plone Site
Added Plone Site
Finished

The site is now put back into its original state. This makes use of buildout's ability to change a part's variables from the command line. Just be careful not to run this on production!

The second option allows you to skip loading up the Plone site during the buildout run. By default, each time you run your buildout with the Plone site recipe installed, it will start up Plone and apply the profiles listed. With the enabled option, this can be avoided if there is no need to run the profiles (e.g. just making a buildout config change).

$ bin/buildout plonesite:enabled=False

On this run, the build will happen much faster as it does not need to start up Plone.

Conclusion

This recipe has helped Six Feet Up simplify the development and release process for its projects. Using the Plone site recipe automates much of the process and means that less human interaction is needed in order to ensure build quality. This also makes sure that setup code remains under version control and can easily be reviewed, modified and passed on to the next developer or release environment.

See more detailed documentation on the product page on plone.org.

Transmogrifier: A Pipeline for Easing Migration into Plone

Clayton Parker — Tue, 30 Aug 2011 16:30:00 -0400

inertia (ɪnˈɜːʃə, -ʃɪə)

The tendency of a body to preserve its state of rest or uniform motion unless acted upon by an external force

Inertia is the tendency to resist change. In the end, it may be the single force that keeps people using the wrong CMS for longer than they should.

When it comes down to comparing Content Management Systems on a technical basis, it's pretty straightforward to figure out the features you need, how you want to deploy, what underlying technology you want to be on, and which CMS is the best fit for your business. Where the issue of whether to move or not often arises is not with the seemingly larger issue of technology, but with the "soft" issues of existing content and how it can be migrated between systems. This is because in so many migrations, the process of getting information to move from one system to another creates a huge time sink for staff time, IT resources and frustrated end users just to get the new system "back to where we were in the old one."

In these instances, content creates inertia behind the existing system, making it more difficult to change directions based on the amount of content you have.

Large sites, loaded with content and standing to profit most from a top notch CMS, often limp along for years because the task of moving seems so daunting. This is particularly true with homegrown CMS implementations. Others never make the move until something like a catastrophic system crash, the CMS going out of business or some other disaster forces the move to be made. Nothing is quite as painful as a rushed migration, yielding sub-par results and devouring time as users work frantically to fix links, reorganize content in what is often a manual and terribly tedious process.

Migrations - the "before" case

When migrations were made in the past, they were mostly technological hacks - one-off scripts, random modules of code from all over the place, strung together to handle a specific migration from point A to point B. And, once you were done with the migration, you never touched that code again. These migrations are expensive to write, hard to replicate consistently, and prone to failure when even the smallest parameter changed. The next time a similar migration came up, you might dig into that code as a resource, pulling out bits that were useful - but for the most part there was very limited or no reusability.

Migrations - the "after" case

I recently did a presentation at the Plone Symposium East at Penn State on the subject of "Migrating from Drupal to Plone" that showed off Transmogrifier, a Plone tool which offers a different and better way to look at migrations. Jarn originally developed Transmogrifier back in 2008 for a specific migration, then donated it back to the community - something they deserve a lot of appreciation for. The framework has seen a lot of growth in the last year or so as many people working at doing migrations began to see the advantages of an approach which could be re-used.

Transmogrifier is a framework for doing migrations which is built on a set of reusable parts which you can add to and share with the community. That way, the next time someone wants to do a migration which someone else has already worked out, its simply a matter of downloading the module for that migration - called a Blueprint - adding it to your pipeline - and you're good to go.

Understanding the terms

A Pipeline is a series of steps written in Python and used to move content from one place to another very much like a physical pipeline does. A Transmogrifier Pipeline is made up of three things - in addition to Blueprints there are also sources and sections.

Sources are Blueprints that know how to bring data into the pipeline - extracting it from a database, pulling it from the filesystem or otherwise getting it into a form where it can be worked with.

Sections are analogous to sections of pipeline, each being a step that is gone through in translating, rearranging and transferring content through the process. Plone users will see Sections as similar to parts in a buildout which can be moved and arranged to provide the desired results.

So what does a pipeline look like?

[transmogrifier]
pipeline = 
    csv_file
    constructor
    schemaupdater

[csv_file]
blueprint = collective.transmogrifier.sections.csvsource
filename = my.migration.import:my_items.csv

[constructor]
blueprint = collective.transmogrifier.sections.constructor

[schemaupdater]
blueprint = plone.app.transmogrifier.atschemaupdater

Once you have created your pipeline, it is time to run things though it. In Transmogrifier, what you run through your pipeline is Items. Items are content elements which are being moved through a pipeline and each is a mapping of content in one form to another. Items may contain keys, which are fields - and keys with a leading underscore are controllers; basically attributes which can be applied to a piece of content you are creating.

As an example, let's say you start with items which have been extracted from Drupal in CSV format using a source. A set of items might look like this:

_path        , _type    , title         , description
/folder1     , Folder   , First Folder  , This is folder One
/folder2     , Folder   , Second Folder , This is folder Two
/folder1/foo , Document , One Foo       , A document named foo
/folder2/foo , Document , Two Foo       , Another doc named foo

After being run though a pipeline, these items become Plone objects as shown below:

The real value in the process is that these blueprints and sources can be built once, and then shared with the community for reuse - so the only parts you need to build are the ones which are unique to your situation, rather than having to reinvent what other people have already figured out.

Migration Strategies

With Transmogrifier in your bag o' tricks, building a migration is relatively straightforward.

Investigate the source program - that is, find out if there are easy ways to get the system you are starting with to dump out its content into a standard format like csv or json. If there is, that might save you having to create a a source which extracts it or pulls it off the filesystem. If a system's background is in SQL, I quite often use SQLAlchemy - though I will always look to see if a) the system offers exports and b) if the exports contain all the information I need.

Prepare the destination - in the Plone site you are moving content to. This can mean creating or setting up custom content types which are analogous to the types of content coming from the source system.

Find Transmogrifier Blueprints - go to PyPI and search for "transmogrify". You should find some helper blueprints to get you started. This will give you a good idea of what work is already done, and what you will need to do. Our goal for the long term should be filling up PyPI with a variety of Blueprints which address as many contingencies as possible so that the people doing migrations have to do less and less of the coding and heavy lifting.

If there is one thing I would like to point out here, its that donating back good blueprints to the community is potentially a huge leg up to others who are in situations similar to yours. The more of these Blueprints we have, the more different systems out there can be cleanly and easily migrated into Plone. The documentation on Transmogrifier is excellent, and the system does such a good job that writing a migration from scratch instead of just coding the special piece you need seems a colossal waste of time.

Finally, for what is left, write your own blueprint for the parts of the migration unique to your circumstance.

Making your migration happen

The preferred way to use Transmogrifier is to make the migration part of your release via GenericSetup. This gives you the chance to package your migration as a part of a profile and run it automatically as part of your release using collective.recipe.plonesite. I will go over this in more detail in a follow-up post.

An example migration - Drupal to Plone

Going back to the original purpose behind using Transmogrifier in my case - migrating from Drupal to Plone. Here is how that process went:

First, I used the transmogrify.sqlalchemy source to pull the content of the Drupal site out so I could get access to it. From there, I used blueprints to move the content into Plone 4.0.5, and also to organize certain pieces of the content so they could be imported as objects into two Plone custom content types - collective.blog.star for migrating blog entries from the standard Drupal blog type and plone.app.discussion for the regular Drupal discussion items.

I created a package which held the elements that made up the whole migration - which is useful from an organizational standpoint as well as when you need to go back and do something again. I also registered configs because the query for each type was slightly different, and this allowed me to do exactly what I wanted for each of them.

Probably the most exciting thing here was that I was able to use blueprints which were already in existence for the vast majority of the migration. In fact, I demonstrated at PSE a migration from Drupal to Plone which required no extra Python code in addition to that which already existed in blueprints. The only coding involved was writing TALES expressions - a far cry from what is normally a marathon of hacking, pasting and testing code in order to get something that works for only one specific case.

There are a tremendous number of options available to you that I'm not even touching on here - so instead of trying to make this a comprehensive guide I suggest you watch my presentation from PSE2011 AND visit the Transmogrifier documentation on PyPI to find out what you need. It is a very well documented project, and those docs will get you a long way into creating and running your own pipelines.

The Fine Print

There are limitations to Transmogrifier - or at least places where you need to take care. If someone has customized their Drupal site, for example, you need to watch out for that and take those changes into account in your pipelines.
There are also plenty of cases where no one has so far written a blueprint to handle the migration. Searching PyPI will bring up plenty of examples that are already out there, but there is still an opportunity for people interested in creating a blueprint and donating it to the community.
Pipelines are not difficult to write, but do require some special knowledge and an understanding of how Transmogrifier works. For example, if you are migrating from something with an SQL backend, someone with a PHP background should be pretty comfortable. But if all you know is Plone and Python, you will face a learning curve.
Since Transmogrifier has a dependency on CMFCore, it is not as straight forward as it could be for migrating to sties that are not CMF based. So it is currently very much a tool for getting content into Plone, not something that is a general-purpose migration tool allowing you to move content from A to B to C to D.

So how does this address inertia?

Transmogrifier does for migration what the assembly line did for mass-produced products. It takes advantage of standardization and the ability to reuse standard parts in many different configurations to move content from System to System in a light, fast, predictable way. In the end, the ability to move content out of a CMS that isn't meeting your needs becomes viable at the point where the pain of making the move is less than the pain of continuing with the status quo. Efficient migrations get rid of inertia as a blocker to making choices an organization would otherwise make without delay.

Of course the flip side of that coin is the argument that once content is moved into Plone, what protects the user from vendor lock-in when they want to get their content out of Plone and into somewhere else? There are a couple of good examples of how this issue can be addressed. First, quintagroup.transmogrifier includes a facility for exporting site content with compatibility back to Plone 2.1, and another product - Content Mirror (which is no longer being actively maintained) - allows content to be moved from Plone into a relational database. Each of these options stops Plone from being a digital black hole.

I think Transmogrifier is an exciting tool at the disposal of Plone developers which can become a big advantage as more and more Blueprints are developed. As we at Six Feet Up found out in our recent migration of a site from Liferay into Plone, this approach has some real benefits both in terms of quality AND speed of doing migrations. We plan on donating Blueprints to the community as we develop them, and hope that other developers and Plone companies will do the same.

Last Question - Why is it called Transmogrifier?

The Transmogrifier was an invention of Calvin (of Calvin and Hobbes fame) which could turn one thing into another. In the comic, it was an inverted cardboard box with a dial on the side which could be set to whatever the user wanted to become. In this case, the dial would be turned to "Plone."

How to move machines between racks without interruption

Calvin Hendryx-Parker — Thu, 11 Aug 2011 10:50:41 -0400

Six Feet Up has been heavily involved in a major hosting infrastructure upgrade that includes moving machines between racks.

Moving servers to another rack requires powering the machines down and it is always difficult to move critical services such as LDAP and DNS. LDAP handles authentication into servers, and DNS manages domain names. Typically, taking down those services results into visitors not being able to reach their sites and/or log in. Since many of our clients' sites require
high availability capabilities, shutting down our LDAP and DNS machines simply wasn't an option.

Instead, we used Common Address Redundancy Protocol, an OpenBSD technology we use on FreeBSD, to handle the move in a seamless and error-free fashion. LDAP and DNS were already running on two redundant machines; CARP allowed us to power down the master, move the machine, and simply hit the power button to bring up the master again with almost no service interruption. Within a few seconds, the backup machine became the master so we could move the machine, and as soon as the new machine got powered on, CARP renegotiated the virtual IP, and the re-racked machine became the master again.

Thanks to CARP, we are able to offer high availability hosting even when moving servers around. FreeBSD Rocks!

Gain 7% More Space in a Hosting Rack

Calvin Hendryx-Parker — Wed, 10 Aug 2011 07:33:33 -0400

Our state-of-the-art colocation facility, Lifeline Data Center, charges us by the rack, which means we have a strong incentive to use the space in our racks as efficiently as possible.

Considering we have 3 Power Distribution Units (PDUs) per rack, we looked at a way to regain the 3U (a U is a unit of measurement in a rack - and usually a server takes up one U) that they occupy in each rack.

After much investigation, we switched to Geist 0U PDUs as they cleverly sit behind the servers, on the back of the rack, hence saving up valuable space for our customers. While this works great, we ran into a compatibility problem between our new PDUs and our Dell racks as the Geist PDUs are 1/8 inch too wide and don't fit in the racks properly.

What's the son of a machinist to do? Exactly that: call upon the family's expertise to get custom-made standoffs for the PDUs. They consist of a few pieces of steel with screws that hold the PDU to the frame without altering the rack.

Now we can fit more billable servers in our racks thanks to saving PDU space and installing more efficient PDUs. Thanks Dad!

A Simple Tool To Protect Expensive Server Rooms

Calvin Hendryx-Parker — Tue, 09 Aug 2011 09:59:14 -0400

If you are running your own server room, read this as it could prevent you from losing hundreds of thousands of dollars.

Upon customer request, Six Feet Up has been operating its own Disaster Recovery Center for two years, providing our clients with highly available hosting that they need to power their mission-critical services.

The Six Feet Up Disaster Recovery Center has several racks and multiple fiber connections. The room has a dedicated heating and cooling system as servers are very sensitive to temperatures and can easily overheat and die in strange ways.

This summer has been one of the hottest ones in Indiana to the point when even our office space got a bit warm on a few scorching days.

This past Friday, at the time when most hardware issues happen or 5pm, our environmental and video monitoring device, a NetBotz, sent us an email to alert us about a rise in the Disaster Recovery Center controlled environment's temperatures. We immediately contacted our heating and cooling vendor, Dial One, who was then able to fix the issue within an hour.

The ability to quickly address a temperature issue in our server room is critical as it guarantees against "inexplicable" malfunctions down the road, and, more importantly, protects our expensive hardware investments. Be sure to carefully monitor your server room's temperatures!

Dell’s Crowbar Looking Very Promising

Calvin Hendryx-Parker — Fri, 29 Jul 2011 14:15:00 -0400

While at OSCON this week, I got the opprotunity to sit in on the Dell Crowbar presentation and live demo at their booth. Crowbar is an OpenStack installer and much more from what I could see. They have combined some very nice tools into a useable UI to get off the ground quickly and manage the growth of your cloud.

One thing that really impressed me about the project though was their aparent dedication to making this Open Source. Seems like a lot of the exhibitors are sporting their wares at OSCON to support Open Source development with their commercial products, but in this case, Dell has put the project on GitHub for everyone to participate in. I have a feeling this will be very disruptive and may put them ahead of the curve when compared to some commercial offerings like Nebula.

I’d encourage everyone to check it out if you are at all interested in OpenStack and cloud computing. Let me know what you think.