I’ve been using this little rake ditty for awhile, to refresh my current development database with data from the production server:
namespace :db do
namespace :production do
desc "Recreate the local development database as a clone of the remote production database"
task :clone do
system %Q(ssh [db_host] "rm /tmp/out.sql.bz2; mysqldump -uroot -p [production_database_name] > /tmp/out.sql; bzip2 /tmp/out.sql")
system %Q(scp [db_host]:/tmp/out.sql.bz2 .)
system %Q(bzcat out.sql.bz2 | mysql -uroot -D[development_database_name])
system %Q(rm out.sql.bz2)
end
end
end
Of course, you’ll have to change the bits in brackets to fit your particular situation.
Now, this obviously isn’t for everyone, but for small-to-medium sized databases it works pretty well and helps you work with real data.
I’m fascinated with the idea of git not just as a version control system for source code, but a redundant, version controlled filesystem for anything.
Take git-wiki for example. It uses plain text Textile/Markdown files in a git repository as its database. You get all the benefits git users have for source code, but for wiki content. I’ve written a little scenario demonstrating some of the strengths of the platform.
Just by using git, you get:
- version control: with past revision rollbacks, diffs, the whole lot
- redundancy: you can push up your entire wiki, with all changeset history, in seconds to multiple locations for backup
- security: since each blob is referenced by a cryptographically-secure SHA1 hash, as is each commit, you can be sure your wiki hasn’t been tampered with
- offline access: you can pull your entire wiki, again with all changeset history, to edit and interact with offline
- branching: make radical changes without affecting the mainline
The concept seems to apply well to a wiki, but I think they’d work as well in a CMS. Imagine being able to pull down an entire site’s content, create an experimental branch of content, refine it, then push it back up to your site: all while having the freedom to go back to any point in time in seconds.
The CMS backend (if there even is one) would still allow you to make changes online, but would check them in the git repository to be tracked. Stylesheets, images, original assets, and so on could be versioned along with the text, since git is so efficient even with binary files.
I’ve gotten a respectable amount of work done on sitesmetric, insofar that it actually downloads data (intelligently) and displays it (somewhere intelligently)
Sneek a peek:

Head on over to sitesmetric to signup and be notified of the beta program, opening soon!
Yes, I’ve started yet another project. I’ve got tons of cycles spent on this, so I hope to be able to execute a really simple v1.0 and get it launched ASAP. The splash page is up. Go check it out in another tab... I’ll wait.
One interesting aspect of this project has been the planning. The really early conceptual stuff I did on MindMeister. What a great way to hammer out all the aspects of an idea you have kicking around your head. MindMeister allows you to be as broad (I started with a quick elevator pitch) or as deep (schema, models, controllers) as you want.

After this step, I used Fireworks CS3 to mockup some screens. Now, I thought Fireworks was just Macromedia’s wimpy Photoshop clone but since Adobe swallowed it, I think it’s trying to be a rapid prototyping tool. Which is fine by be, it worked great. I’ve never really worked with anything at this stage that let me mold pixels as easily as putty:

Without divulging too much, of course, here’s the pitch. (There are still some legal issues I’m working out with the largest search engine company.) It grew out of my frustration of trying to keep track of all the loose ends of various sites. dotfiles, lifemetric, taglol, this blog; they go on and on. All the information I needed wasn’t all together, so stuff randomly fell through the cracks and I didn’t know about some of the things I probably should have. I hope sitesmetric will fill this gap.
So imagine sitesmetric as being the one place you can go to see the latest traffic trends; mentions on sites like Digg, Slashdot, reddit, etc.; keyword positions; domain registrations; hosting details; and so on.
In the coming days I hope to share some more mock ups and comps.
Merb, like Rails 2.0, sports some very flexible asset helpers. But Merb’s asset helpers bring a whole lot more to the table in terms of flexibility, speed, and features. Kinda like Merb itself.
Take js_include_tag. Sure, you can just throw it in your application layout and include some Javascript on every page like you would with Rails. You can even “bundle” all your Javascript assets. No, not manually. Merb is smart enough to give you the flexibility of separate files in development mode, but give you the extra speed boost in production mode. This is probably old news to a lot of Rails developers that haven’t been under rocks for the past year.
But, Merb gives us even more flexibility. What if you want to minify your Javascript? Merb supports asset bundler callbacks, which let you run some code after a bundle is created:
Merb::Assets::JavascriptAssetBundler.add_callback do |filename|
system("/usr/local/bin/yui-compress #{filename}")
end
Pretty cool huh? Now, you could come close to this in Rails with something like PackR but it gets better:
If you’re the kind of web ninja who keeps their Javascript or CSS separated, it may be kind of cumbersome to figure out which assets you should be including and when. Not with Merb. Enter include_required_js and include_required_css. Throw these two methods in your application layout and you now have the flexibility to specify what Javascript or CSS files to include for what view. In the view. Where it makes the most sense:
<!-- application.html.erb -->
<html>
<head>
<%= include_required_js %>
<%= include_required_css %>
</head>
<body>
<!-- SNIP! -->
</body>
</html>
<!-- list.html.erb (or any view or partial, really) -->
<% require_js 'auto-complete' -%>
I can see this making a lot of sense for including something like Javascript auto-completion or calendar popups only on pages that actually require them. Which is a huge win for the other, say 90%, of your pages that don’t require the Javascript file to be present.
P.S. Props to the Merb team for creating clean and well-documented code that makes finding gems like this easy (and maybe even a little fun) to find.
If you encounter this issue booting up a Mongrel:
$ ./script/server
/Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- builder/blankslate (LoadError)
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require'
from /Users/kmarsh/Sites/sampleboardportal/vendor/rails/activesupport/lib/active_support/basic_object.rb:3
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require'
from /Users/kmarsh/Sites/sampleboardportal/vendor/rails/activesupport/lib/active_support.rb:29
from /Users/kmarsh/Sites/sampleboardportal/vendor/rails/railties/lib/commands/server.rb:1:in `require'
from /Users/kmarsh/Sites/sampleboardportal/vendor/rails/railties/lib/commands/server.rb:1
from ./script/server:3:in `require'
from ./script/server:3
...it’s because you’re missing Builder. Try a sudo gem install builder. Fixed the issue for me!
It really is a no brainer to setup Linux, MySQL, Ruby, RubyGems, RMagick, Rails, etc. the 45th time you’ve done it. But it takes a bit of time to go through those 44 other times. So I decided to write down all my steps so I can consistently setup a box at will with little fuss. Take a look, it probably is very close to what you’re looking for:
Ubuntu / MySQL / Rails Stack Install Guide
Kevin Rose has stated he intends to stop the censorship of the posting of the (now) infamous AACS code.
The only way Digg can redeem itself now in the minds of its followers is to be sued by the MPAA, fight it, take the case all the way to the Supreme Court, and have the DMCA deemed unconstitutional and overturned.

So, Coda is out and it has been pretty well received. For good reason. It’s a very elegant-looking app, with nice touches all over the place. Panic really knows how to exploit the look and feel of OS X and the core technologies beneath. Put simply: it oozes Mac goodness from every corner.
I want to use it, I really do. However. I don’t need it.
You see, ever since I switched from PHP to Rails I only touch the server for little increments at a time, and no longer work directly on it (man, those were[n’t] the days!) Even when developing comps from Photoshop to XHTML/CSS, I mainly stay within my current editor and switch back and forth between Webkit.
(As an aside, I really like the bundled Panic Sans font. Appears to be some variation of Bitstream Vera Mono, possibly with the underscores tweaked.)
So all this talk about Rails (not) scaling got me thinking. If the database is the next bottleneck after you’ve beefed up your pack of Mongrels, just remove it—and replace it with Twitter!
That’s right. A Twitter-based ActiveRecord store.
I expect the plugin to work something like this:
development:
adapter: mysql
database: sockr_development
username: root
password:
host: localhost
test:
adapter: mysql
database: sockr_test
username: root
password:
host: localhost
production:
adapter: twitter
username: sockr_production
password: web2point0h
(Note here how I’m still using a traditional RDBMS for development and test environments. Kicking in Twitter here would be quite silly, as we don’t need the scalability for just our local user as we’re developing. We really need it for production!)
That’s it! The plugin would take care of marshaling your ActiveRecord objects into 140 byte chunks and sending it off to Twitter HQ for cold storage.
Keep your eyes peeled for the plugin, coming soon!