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).
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:
Improvements:
Bug Fixes:
Depreciations/Moves:
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.
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.
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:
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.
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:
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!
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:
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.
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:
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?