My book Merb in Action, is available now in Early Access from Manning Publications

Wednesday, August 06, 2008

APIs, and guessing what users want

I added Twitter support to Divvs yesterday. I had started it a while back, and then other things became more important, but since we’re getting Real Close to calling it “alpha” I figured I’d wrap it up.

I ran into an interesting snag with the Twitter API: it’s too clever.

I think Twitter assumes that most people using the API are writing clients of either a web or desktop variety. They also have a very strong need to limit how much data gets returned. So most of their API calls have paging, where you only get 100 records back, and have to pass in a page param to get the next set.

In our case, all I want is a list of the user’s friends and followers. I don’t need their status updates, details, pictures, or anything else.

I’d like to do something like this:

The problem is, I only get the first 100 in each call. I have to page through. Here’s what I ended up with:

This means that even for the best case, I’m doing 2 calls when 1 would suffice. Worst case, I’m doing 7, 10, 15 calls.

I’m not actually complaining about the Twitter API. They’ve optimized for their normal cases, and when I ask them about this I bet they’ll add something to turn my 15 calls into 1. (Even if they don’t, it’s not a big deal, since it works.)

It just reminds me that all too often, we assume we know what our users need. We don’t, though. They find new needs, and work around us when we get in the way.

Tags:   

3 comments

Thursday, July 31, 2008

Need a Rails/Merb development team?

I haven’t been actively looking for clients with Ivey & Brown for a while. Between existing work and Divvs, we’ve kept pretty busy. For the next month or so, though, Don and I have some time to take on a new client or two. If you know anyone who needs a pair of really good developers (we can scale to a team of 4 or 5 if needed) for a Ruby, Rails or Merb project, let me know. We offer a pretty good referral fee, too.

0 comments

Thursday, July 31, 2008

Update

Sorry I fell off the planet there.

Summer is a really crazy time for me, mostly because the last week in July is SUUSI which means last-minute SOLIS fixes. This year was my 20th SUUSI, every year since 1989 (except for 1992, when I met Emily at GHP). For the past 2 years, I’ve been building a Very Large Rails app called SOLIS to handle all of the registration, workshops, scheduling, credit card processing … it’s the brain behind a lot of SUUSI. I still surprise myself with how useful it is sometimes.

Case in point: Friday night at the play, a woman came in with a lost kid. He didn’t know his room #, Dad’s cell #, anything. So I pulled SOLIS up on the iPhone, looked him up, had his Dad’s cell # and his Grandmother’s home # ready to go. 2 years ago, we would have had to try and find someone with access to the computer system, or paper printouts. I wrote the thing, and I still got excited using it.

It’s Thursday night now, nearly a week since we got home, and I’m still not 100%. I can’t really explain what SUUSI is like, or why all of us who go need a week or two to decompress when we get home. It’s the longest week of my year, though.

In other news…I kinda mentioned, but didn’t really blog about the fact that Don and I started a new company. Divvs gives you a way to take the value of your social network connections and represent it with a numerical rating. We’re still working on our rating algorithm, but we’ve come a long way in a few months.

Chapter 2 of the book is available in Early Access.

I’ll be at the Ruby Hoedown next week. Oh, and I’ll be in Atlanta on the 4th, if anyone wants to get together for dinner at Manuel’s.

0 comments

Friday, June 20, 2008

Impediments

I’m supposed to be working on the book right now. Finishing chapter 2, to be precise. That’s what I’ve been doing all day.

Guess how many words I’ve written. Go on, guess.

That’s right, none! Nary a word.

I’ve helped Emily get Ellie in, and out, and in again, and right back out of her new sling.

I’ve cleaned up birdseed, after William Henry got into it.

I’ve been to Wal-Mart, the grocery store, the library and the Post Office. (Note to the two clients who didn’t send me checks yet: uhm…please do that.)

I’ve got the new Weezer album on, I’ve had a Dr. Pepper, and I’m going to crank some words out, dammit. Good ones, too. These are about to be some really stellar words. Just you watch.

Tags:  

Friday, June 13, 2008

Internet Speed

Around 2 PM, I heard via Twitter that there was a rumor that Tim Russert was dead. Since I’ve been a mostly-regular MTP viewer for years, I started following the information really closely for a little bit.

I checked Google News but there was nothing. Same with Blog Search and Wikipedia and a few other places.

When I checked again five minutes later, there was a single post on Google Blog Search, asking if anyone else had heard the rumor. Google News still had nothing. It was strange to be pretty sure some news had happened, and yet not see it on the political blogs.

Five minutes later, the NY Post had broken the story, it was on Drudge, and Blog Search had posts from people blogging they had heard it on the radio. NBC didn’t cut in to the golf game with Brokaw’s report for at least 10 more minutes. CNN waited on them, but the blogosphere was already aflame. The internet moves fast.

It will be weird not hearing Russert’s take on this coming general election and Sunday afternoons (I TiVo MTP) will be very different.

Tags:   

Friday, June 13, 2008

Tests make you write better code

Michael Feathers has an article about Unit Testing that’s going around. The gist is:

“All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.”

I’m feeling that very directly right now. A client project I’m working on doesn’t have any tests, other than the skeletons Rails creates, which don’t run cleanly anymore. So we’re running without tests, which I haven’t done in a long time on any kind of serious project.

What I’ve discovered is that I make a lot more stupid mistakes that I never would have made with a decent test suite. It’s not that the tests would catch the mistakes. I never would have made them to begin with. From really questionable naming choices to silly little thinkos, I keep going back to revisit things and I say to myself, “Wow, what were you thinking?”

I wasn’t. Not as much as usual, since I didn’t stop and think about the test first.

What do you do when you come on a large project with no test suite, and no budget for retroactively creating one?

Tags:    

Saturday, April 19, 2008

Engine Yard

As I mentioned on Twitter, Friday was my last day at Engine Yard. Since several people have asked, I wanted to say a little bit about why I decided to leave and about what’s next.

First off, I can’t say enough times how much EY rocks. They’re an awesome company to work with (I’ve been a customer) and an awesome company to work for. I had a great time working with some very talented people.

What it really came down to was time. I used to laugh when political figures would resign to “spend more time with their family,” but that’s basically what happened for me. I realized that the most valuable thing I have in my business life is the flexibility to wrap it around my family life, not just after dinner or over lunch, but all day. As a fulltime employee, I couldn’t take off the afternoon because Ellie was feeling cranky and needed extra attention, or because she was being silly and I wanted to spend a few hours being charmed. It wouldn’t be fair to my co-workers, or the customers. Being self-employed gives me control over my time and how I assign it to projects, and I really missed having that control.

What’s next? I’m back to consulting with Ivey & Brown (that website is sorely in need of a makeover). If you need some contract Merb or Rails development or Scrum training, give us a call. I’m working on some internal projects in May (see website above) and will have serious time for client work June 1.

A couple of people asked me, “Aren’t you scared, not knowing where your paycheck will come from?” and the answer is, “Yes!” Sometimes being self-employed is a real nail-biter. It takes a fair amount of ego self-confidence and a willingness to take risks. For me, the risks are worth it, but it’s definitely not for everyone.

Yes, I’m still involved with Merb and hope to actually be more involved in the coming weeks. I’ll have more time to focus on getting 1.0 ready, and on the Merb book I’m co-authoring for Manning. I think my editor will be happy about that aspect of my flexibility, for sure!

Thanks to everyone at Engine Yard for being awesome. It was a blast, and I can’t wait to have some new apps for you to manage.

Saturday, March 01, 2008

Quickie: sake tasks for Merb hackers

If you hack around on Merb itself, take a look at these sake tasks


$ sake -T http://merbivore.com/merb-dev.sake
sake merb:clone          # Clone a copy of all 3 of the Merb repositories
sake merb:update         # Update your local Merb repositories.  Run from
 inside the top-level merb directory.
sake merb:gems:wipe      # Uninstall all RubyGems related to Merb
sake merb:gems:refresh   # Pull fresh copies of Merb and refresh all the
 gems
sake merb:install:core   # Install merb-core
sake merb:install:more   # Install merb-more
sake merb:install        # Install merb-core and merb-more
sake merb:sake:refresh   # Remove and reinstall Merb sake recipes

The code is served piping hot direct from GitHub so it’s always current. If you’d like to contribute, let me know and I’ll add you.

Tags:    

Thursday, February 28, 2008

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.

Saturday, February 23, 2008

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.

Tags:  

Tuesday, February 19, 2008

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

Tags:  

Wednesday, February 13, 2008

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

Tags:  

Saturday, February 09, 2008

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.

Update your ticket and add: 
   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

Monday, February 04, 2008

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.

Tags:  

Thursday, January 31, 2008

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

Tags: