Thinking about getting TiVo? Use me as a referral.

TiVo has a rewards program, which they’re phasing out. The last day to earn any referral points is April 30. So, if you’re thinking about getting TiVo sometime soon, please get it before April 30, and please use my email address for the referral.

Why should you do this?

Because, for every referral I get 5000 points. For 500 points, I can order 5 (yes 5!) 3” TiVo plush things.

This means that if you use me as a referral, and I get 5000 points, and I then order 3” TiVo plush things, I can get 50 of them. 50 3” TiVo plush things if you buy TiVo! How cool is that?

I’ll even share. If you want some of them, and use me as a referral, I’ll send you some. Heck, I’ll send you some even if you don’t, if I end up with enough.

My goal is to have enough to fill the bathtub. Or maybe Ellie’s crib. Or the Jeep.

A simple re-tweet script

I want to be able to tweet as Ellie from my phone, without logging in and out of the web interface. So I made a simple re-tweet script that will let me send direct messages and have them get posted.

#!/usr/bin/env ruby

require 'twitter'
twitter = Twitter::Base.new('USERNAME', 'PASSWORD')

retweeters = ["ivey"]

twitter.direct_messages.each do |message|
  if retweeters.include? message.sender_screen_name
    twitter.update(message.text)
  else
    twitter.d('ivey',"#{message.sender_screen_name}: #{message.text}")
  end
  twitter.destroy_direct_message(message.id)
end

Be sure to change my username to yours (in both places). Run the script via cron how ever often you like.

michael.has_baby? => true

The title of this post (which is “michael.has_baby? => true” despite what the CSS has done to it, and that I am too tired to fix) may be the only Ruby content around here for a little while. I mean, how can you think about Merb or HTTP headers or how much GitHub rocks when you’re looking at this adorable face?

This is Ellie. Eleanor Airey Ivey, born Feb. 18, 2008. Mom and baby are well, pictures headed to Flickr and to http://ellieivey.com

Merb 0.9.0 (developer release)

A few minutes ago I pushed the gems for Merb 0.9.0 “All you need, none you don’t” to merbivore.com. Before you run off to “gem update” there’s some things you should know.

As wycats explained earlier we’ve chopped Merb up a little bit. merb-core is small, fast and just the stuff you need to build a basic web application. merb-more is a collection of things that make it cooler and more useful, like mailers and generators and template engines. Together, merb-core and merb-more make up “merb”. You’ll still be able to gem install merb and have it work, or you can cherrypick just the pieces you want for your application.

We’ve also got a decent collection of “official” plugins, including all the ORM plugins, and some additional rspec and test/unit support.

Anytime you gut a codebase like we did with Merb after 0.5, there’s stuff that doesn’t shake out properly. We had planned to release 0.9.0 last weekend during acts_as_conference, but there’s still some little stuff that needs shaking.

Normally, we’d just get people to use trunk and see what needed doing, and then call it a release. This time, we don’t really have a good sense of exactly where the rough spots are between all the moving parts.

We need your help.

Here’s 0.9.0, and it’s a real release. It’s official. It’s just not on the Rubyforge gem repository yet. We’re calling it a “developer release” and it’s like a release candidate, except we don’t think we’ll actually release it. Once people use it, and we oil some of those squeaky spots, we’ll push an 0.9.1. We may do a few of these developer releases before we decide we’re ready to push it to Rubyforge for general consumption.

These developer releases are here to make sure that Merb 1.0 is as good as it can be, so if you want to see an awesome Merb 1.0, please use these 0.9.0 gems, and future dev releases, and give us feedback.

If you have RubyGems 1.0.1, and want to always use these developer releases whenever they’re available:

$ gem sources -a http://merbivore.com
$ gem install merb

If you don’t, or you don’t:

$ gem install --source http://merbivore.com merb

As always, put your bugs and patches in Lighthouse and join the discussion on #merb.

PS: Want to see something cool?

$ merb-gen myflatapp --flat
$ merb-gen mysinglefileapp --very-flat

Contributing to Merb (Part 2)

In Part 1 I talked about how to use git to work on the merb-core/merb-more projects that will be Merb 0.9.

This time I’ll show you a different workflow, for people who plan to make a lot of changes, or want to do something interesting and maintain it as a public fork.

Forking is sometimes a bad word, but no more! In this new gitastic world, forking is a cool thing. That’s why Github makes it so easy to do! When you fork, you do the same thing as when you clone….you just make your clone accessible to the world.

Step 1: Fork

Every Github project has a prominent “Fork” button, if you’re logged in.

So the first step is to click that button. As simple as that, you’ve made your own repository based on the original. You can add other people to it, accept patches, whatever you like. (In fact, I really hope someone will fork merb-core and merb-more, declare themselves to be the coordinator of documentation patches, and periodically feed those back to the main repos)

Play around with the settings. You can’t break it, and if you do, you can delete it and start over. Forks are cheap.

Step 2: Clone your new repo

Instead of cloning wycats’ repo, you want to clone your own. For instance, I have my own merb-core for experimental stuff, or if I want to give someone commit for a while to work on something together. When I clone my repo, I use the following:

$ mv merb-core merb-core-official
$ git clone git@github.com:ivey/merb-core.git

(This is not completely true. I have a much more complicated setup, which I may detail in Part 3)

Now, you probably want a way to keep in sync with the official repo. So let’s add it, too:

$ git remote add official git://github.com/wycats/merb-core.git

Now, anytime you want to sync up, you can use either of the following:

$ git pull official master
$ # or
$ git fetch official
$ git rebase official/master

The first version does an automatic commit of the merge, the second doesn’t.

Step 3: Fix stuff

This is where it gets fun. This is your repo. Make some changes. Use ‘git push’ to push them up to your github repo. Share them with #merb. Get people to run your version and try the changes out. Fix bugs.

If you’re hoping to get your changes merged back in, it’s a good idea to communicate with us about what you’re doing.

If you’re working on multiple big projects, it’s a really good idea to keep each one in a separate remote branch, so we can merge one without merging all of them. We can cherry-pick if needed, but it’s easier if you use branches.

$ git checkout -b feature1      # create a branch
# make changes
$ git commit
$ git push origin feature1      # push feature1 to remote

Or, you can git push —tags and push all of your local tags to your remote repo. Hey, it’s your repo, use it how you like.

Step 4: Getting changes merged

Now you need to get someone to merge your changes. Ideally, you’ll already have an open ticket in Lighthouse, have been in communication with folks in #merb, and maybe even have talked to one of the core devs about your changes.

   Hey, I have this fixed in my repo.

   Please pull:

   git pull git://github.com/jimmyhoffa/merb-core.git feature1

The important things to note are that you use your repo URL, you make it easy to copy/paste directly (starting it with ‘git pull’) and that you include the remote branch, even if it is master.

(Github will soon be adding a “Pull Request” button, so you can notify about patches via Github. Keep an eye out for that.)

If your changes are accepted, you’ll see your commits show up in the main repo and there will be much adulation. Hooray! This doesn’t even begin to scratch the surface of how awesome git is, but it should get you going. Oh, and if you’re like me, you’re dying to know how git works on the inside

Merb Monday

jp_n9 from #merb has started a series he calls Merb Monday where he compiles questions and answers from the IRC channel. This is an awesome idea. I was thinking last night that we needed a “Kernel Traffic” style summary for Merb stuff, and this is an excellent start! Go subscribe, or just check it out on Mondays.

Contributing to Merb (Part 1)

I’ve seen several people ask “How can I help with merb-core?” and so, here’s a little guide. (Updated 2/14 w/ notes on rebasing. Thanks ReinH.)

This is part 1 of 2, for people who don’t want to run their own public fork.

Step 1: Get a Lighthouse account

All of the Merb development is moving to Lighthouse instead of Trac, so you’re going to need an account. Go register and then come back here.

Step 2: Get git

Merb is using git for development now. There’s information on the main git site about downloading and installing. There’s also some guides for installing on Mac. Google is your friend.

You should also configure git with your email address:

git config --global user.name "Mike Tester" 
git config --global user.email "mtester@gweezlebur.com" 

These are global config settings that will apply to every project you checkout.

Step 3: Get Merb

Using git is different from using SVN. Every repository, whether published or not, is on equal footing with every other one. All of the official Merb releases will be coming out of wycats’ repository, though, so you probably want to get that one. Do that with “git clone”

$ git clone git://github.com/wycats/merb-core.git
Initialized empty Git repository in /tmp/merb-core/.git/
remote: Generating pack...
remote: Done counting 1684 objects.
remote: Deltifying 1684 objects...
remote:  100% (1684/1684) done
Indexing 1684 objects...
remote: Total 1684 (delta 800), reused 57 (delta 8)
 100% (1684/1684) done
Resolving 800 deltas...
 100% (800/800) done

This will create a new repository in the directory merb-core, set up the remote repository links, fetch the latest copy of the upstream repository into your repository. and set up a tracking branch for upstream.

Step 4: Fix something

This is the whole point, right? There’s a bug you’re dying to fix, or a feature you’re dying to add. So let’s do that. First, we create what git users calls a “topic branch” to hold the changes for this particular bug

$ git checkout -b my_bugfix 
Switched to a new branch "my_bugfix" 

This creates the branch, and switches us to it. Now change whatever needs changing, of course running the specs to make sure they still pass.

There’s a lot of git commands you may use here that are beyond the scope of this guide, like diff and status. Consult your favorite git tutorial.

Now we need to commit the changes. Remember, in git every repository is equal, so you’re committing to your local repo, not trying to commit to wycats’.

$ git commit -a -v

This will pop open an editor for us to type a commit message. It should have a short, very descriptive first line, a blank line, then any other information that’s relevant.

Added bug zapper library

This loads in the bugzapper library,
which removes some common bugs,
like the ones in ticket #343.

Save and quit, and you’ll see something like this:

Created commit 14626c1: Added bug zapper library
 1 files changed, 2 insertions(+), 1 deletions(-)

The important bit is “14626c1” ... it’s the first part of the unique identifier for this commit. If you ever need to refer to this exact commit, you’ll need that.

However, since we used a topic branch, we know that every commit on this branch is part of the intended changes. So we can use a shorthand to actually generate our patch(es). First, though, let’s make sure we’re current with upstream

$ git checkout master
$ git pull
$ git checkout my_bugfix
$ git rebase master
$ git format-patch master..
0001-Added-bug-zapper-library.patch
0002-initialize-zapper.patch

This says “make patch files for every commit that is in this branch and not in master” (master is the default branch you started with). You can see that I committed another fix, so there are 2 patches.

If the rebase fails, it means your patches don’t apply cleanly with the latest upstream changes. You’ll have to fix that (either manually or using git merge-tool), and then

$ git rebase --continue

After that, continue with formatting the patch.

Step 5: Submit the patche(es)

Go to Lighthouse. Create a ticket. Tag it with “patch”. Attach your patch(es). Wait for them to be applied.

Step 6: Cleanup

You should switch back to the master branch now.

$ git checkout master
Switched to branch "master" 

If your patches have been accepted, you can delete your branch, too:

$ git branch -D my_bugfix
Deleted branch my_bugfix.

Branches are cheap, so you can leave it around for a while, if you think you might come back to it.

You should also pull down the latest changes, so your next patch will apply cleanly:

$ git pull