OneBody

Time Zone Support

Posted by: timmorgan on: October 3, 2008

The next release of OneBody (and the current development code) has support for multiple time zones per installation. Previous releases have stored times in the local time zone, but now OneBody will store times as UTC, and then display them in the current site’s time zone (configurable in Settings).

To convert an existing installation’s times to UTC, back up your database and run the following command:

rake onebody:convert_times_to_utc

But first you’ll need to edit the lib/tasks/convert_times_to_utc.rake file to tell it what your current time zone is (so it knows how to calculate the offset to convert the time to UTC).

OneBody 0.7.7

Posted by: timmorgan on: September 26, 2008

The latest work on OneBody has been tagged and released as version 0.7.7. As with the previous release (0.7.6), the Git tag “stable” represents the latest stable release at all times. Cap deployments by default now point to this tag, saving you some hassle with remembering to update your app (a simple “cap deploy” should do the trick).

This release, while only a minor point release, does manage to introduce a few significant features, and a whole lot of bug fixes. I’ve attempted to capture most of the changes by going back through the Git log.

Features:

  • Add community logos.
  • Allow “off the street” signups for certain types of communities. Sign ups can either be required to be approved by an admin or auto-approved.
  • Directory can now be printed with family pictures.
  • Added ACS Converter to Update Agent.
  • Add legacy/external id editing to person edit form.

Improvements:

  • How group listings are displayed
  • Appearance of site header and slogan
  • UpdateAgent moved to new GitHub project: seven1m/onebody-updateagent
  • Group create/edit experience.
  • Form feedback and textarea styling.
  • Security of mass assignment in profile editing.
  • Appearance of buttons and tabs.
  • Reject mail from/to postmaster.
  • Resize photos to 800×800 max and discard original (this will save hundreds of megabytes of disk space for sizable communities).
  • Add hook to restart scheduler after a standard cap deploy.
  • Ease up log flagging a bit.
  • Set cap deploy.rb example config to checkout “stable” branch by default
  • Update Setup mode to know about stable release vs dev release.

Bug Fixes:

  • Capistrano deployment recipes
  • Bug sending body of email when attachment present
  • Fix bug preventing people being moved to a new family.
  • Fix dates of 0000-00-00 in MySQL.
  • Rake newuser task should add to super admins, not overwrite it.
  • Fix bug creating new site publications group.
  • Fix new note ownership.
  • Fix group category selection and form feedback.
  • Add Publications group for new sites.
  • Generate api key in onebody:api:key rake task if not present.
  • Batch compare and update should take site_id into account.
  • script/inbox should not take –site arg since it is determined by Notifier#recieve anyway.
  • Fix bug detecting secondary host.
  • Fixed incremental search for City and State
  • Fix group membership admin page

Depreciations/Moves:

  • Connector and sync script has been depreciated. Please use UpdateAgent from now on.
  • UpdateAgent has been moved into its own project. Installation is only a “gem install” away.

OneBody for $20/Month

Posted by: timmorgan on: September 17, 2008

I’ve been working off and on with OneBody for about two years now. I’d love to say that hundreds of churches all over the country — heck, the world — are using it. But that’s just not the case. OneBody is complex software, and the number of steps it takes to get it up and running on a server can be daunting, even with all the improvements we’ve made in recent months to the setup procedure, Capistrano scripts, documentation, etc.

Still, there are geeky people in churches all over, that know OneBody could be of use to their church. If only they could have someone install it for them.

Introducing: beonebody.com.

We’re now offering hosted instances of OneBody for super reasonable rates (around $20/month). We won’t make tons of money, but hopefully we’ll be able to make connecting communities on the Web within reach of a lot of small and medium-sized churches.

Check it out.

OneBody 0.7.6 and Update Agent

Posted by: timmorgan on: September 11, 2008

OneBody 0.7.6 has been tagged on GitHub. This release includes several bug fixes and a pretty solid Update Agent script. First, the fixes…

Dan Taylor at PowerChurch Software has been contributing several fixes for bugs the last few weeks. PowerChurch provides a Church Management System (ChMS) solution, and they’re working to ready OneBody as an offering to their customers, fully synchronized and ready to run. Many thanks to PowerChurch for their support of open source.

* * * *

Now, to Update Agent (UA). When I first started hacking on OneBody, my church hosted the software in-house, on a server inside our building. Synchronizing data from our ChMS to OneBody utilizing the Connector was relatively fast (well, fast enough), because it was all on the same local network.

But as OneBody has grown from a little hobby project into a real product, and since our church and others are now hosting OneBody in separate VPS hosting environments, synchronization with the Connector is cumbersome and slow at best (meanwhile, it’s just painful for syncing 20,000 or more people).

OneBody now ships with an API and the Update Agent (updateagent.rb) script to ease the pain of hooking into a separate membership management database. With the ComsConnector, Cedar Ridge Christian Church performed every night a sync of 8000 people in about 1.5 hours and with hundred MBs or so of data transfer. Now, with Update Agent, synchronization takes literally minutes* and only the necessary data is transfered. REST API FTW!!1

Along with major speed improvements, the entire concept of syncing is within reach of more people. UA takes for its input a single CSV file. This should lower the barrier to entry for OneBody a notch or five.

Documentation on the wiki is still lacking, but if you’re interested in the new way to sync OneBody, crack open updateagent.rb and read the instructions at the top. I’ll be working on the docs in the next few days/weeks, and the Connector idea will be depreciated in time.

* First-time sync can still take awhile, but not every time — that’s the key.

Ignoring database.yml

Posted by: timmorgan on: September 3, 2008

This is something that should be done with all Rails apps as they are sucked into The Git for the first time: ignore the config/database.yml file.

Even with as much as evangelism we do regarding using Capistrano, people will still choose to deploy the simplest way they know how, by cloning directly from GitHub to the server. This creates an undesirable effect once the database.yml file is modified to suit the environment… it is seen as a modification to the OneBody codebase. Changes to this file in the origin repository get pulled down on every update, causing problems.

Unfortunately, we failed to ignore database.yml when we converted OneBody from Subversion to Git many months ago. So it has been in the repo, pointing to a SQLite db, causing problems for commiters and deployers.

Now, we’re biting the bullet and getting it done:

  1. We renamed database.yml to database.yml.example
  2. We added code to environment.rb that will copy the example config into place if no config exists.

The side effect is that in your deployment, when you’re ready to get up to date with the latest and greatest, doing a pull will likely rename or delete your database.yml

The fix: copy your current database.yml to a safe place, and put it back once you’ve done the pull. You should only have to do this once, and we’ll all be past this little annoyance forever. Thank you.

OneBody 0.7.5

Posted by: timmorgan on: September 3, 2008

This past weekend saw the polishing and wrapping up of a handful features and a couple of milestones for OneBody, and the tagging of the 0.7.5 release:

  • Improvements to OneBody plugin architecture.
  • Start of attendance tracking for groups.
  • Scheduler now reads tasks from the database rather than files with admin screen to manage scheduled tasks.
  • Better contextual help for admins getting OneBody up and running.
  • CMS can use a page as its template.
  • REST API work, including basic authentication with API key.
  • Improvements to the onebody:sites rake tasks.
  • Improvements to Capistrano install and setup recipes.
  • Passwords are now more securely encrypted.
  • RSA encryption is used with JavaScript to provide added security when signing in and when changing user password (all without the need for SSL).
  • Compression of JavaScript files to lighted bandwidth usage.
  • Linked groups can now have manually added members.
  • A basic REST API is now in place, along with an Update Agent script to sync your OneBody instance remotely.
  • Lots of bug fixes and more regression tests.

OneBody Demo

Posted by: timmorgan on: July 29, 2008

Jacques Crocker has featured OneBody on the Open Source Rails site, and so graciously put up a live demo of OneBody at onebody.opensourcerails.com. (I had turned off the demo awhile back to free up some resources on my host.)

Thanks Jacques!

OneBody 0.7.0

Posted by: timmorgan on: July 23, 2008

I just merged the Refactor branch into Master and tagged the code as release 0.7.0. This is a big milestone for OneBody; lots of things have changed.

The wiki needs some major love, and I hope to get to that later tonight.

In short, some of the new features are:

  • Content Management System
    Use OneBody as your church website and your online directory.
  • Split Theming
    Use a different theme for your public website than for your directory, all from within the same software.
  • Export of People, Family, and Group data as either XML or CSV.
  • Import of People and Family data from CSV.
  • OneBody plugins allow for added functionality without hacking the core system.
  • Simplification of “Shares” into the “More” tab, along with easier picture uploading.

And tons more, including rewrites of nearly every controller to conform to the RESTful Resource pattern, tons more tests, and overall code cleanups.

And we’re not done yet! The OneBody team is growing and contributions are starting to roll in. Expect more great things in the days and weeks to come.

Auto Expiring Rails Caching

Posted by: timmorgan on: July 21, 2008

Rails has some pretty easy-to-use caching built-in. I don’t know about everyone else, but I know for me, the word “memcache” always scared me. It sounds like some ominous, mysterious, magical thing that takes a Ph.D. to understand.

Rails caching, on the other hand, is just Ruby. And I like Ruby.

But still, it seems to be lacking a useful feature, namely auto expiration of cached items based on a timeframe. Sure, since the cache (in my case at least) is just files on the filesystem, I could set up a cron script to remove files older than X hours or whatever. But that didn’t sound very cool. And I’m all about being cool you know.

So I hacked (and I really mean hacked) together auto expiring action caching for Rails. It works, and it works well for OneBody. But, there are some limitations:

  1. It only works with disk-based cache store.
  2. You must explicitly set the path where you want to store the cached content.
  3. I wrote it, so it’s probably not the “Rails way” of doing things.

But it works. Here is the code.

Using it looks like this:
class PeopleController < ApplicationController
  caches_action :show, :for => 1.hour, \
   :cache_path => “…something here…”
end

I would love to get some feedback. Is this worth anything to anyone?

Tags: ,

Routes

Posted by: timmorgan on: July 18, 2008

RESTful Resources kick butt, even if only for the simplicity of the route generation. Check out the difference between the Master branch and the Refactor branch…

config/routes.rb from Master:

config/routes.rb from Refactor:

Just about half the LOC… and much easier to follow.

Tags: ,