1. One side of the check per scan
2. Grayscale
3. 300 dpi
4. jpeg format
5. under 1 MB

I have a nice Fujitsu ScanSnap that outputs a multipage full color pdf. So, I wrote an automator script to take that pdf and split it, convert it to grayscale, save as jpeg while reducing the dpi. Now, you can scan all of your checks to deposit in a single scan and run the automator app.

Grab it from github:

• Download Zip File
• View Source

• redmine
• rubber
• rubinius
• mms2r
• cucumber

Thanks for all the great software!

It isn’t an extreme programming requirement that you’re running on Mac. If you’re deploying on Linux and you’re using Ruby on Rails and vim for your development then logically Linux would be the best OS choice on which to develop. If you’re still sold on TextMate, I’d recommend trying emacs but it is your choice. In that case, you have to compromise your development OS choice and go with Mac.

Everyone I happen to pair program with can use vim. Some of us use Mac others Linux. We also enjoy the flexibility of either going in to the office or working remotely. We’ve tried a couple of different solutions for remote pair programming:

• iChat screen share
  • Easiest network setup
  • OS X only
  • Bandwidth hog (need large pipe on both ends)
  • Sends raw keyboard signals (dvorak/qwerty pairs hard)
• Skype video screen share
  • Easiest network setup
  • Beta OS Support (OS X and Windows only ATM)
  • Bandwidth hog
• VNC and Skype voice
  • Platform agnostic
  • VNC requires NAT traversal
  • Bandwidth heavy (less than iChat)
• SSH, Screen and Skype voice
  • Platform agnostic
  • Very low bandwidth usage
  • Familiar terminal environment
  • GUI text editors not supported
  • may require NAT traversal

We started by trying screen sharing software. This works pretty well with large bandwidth pipes on both ends. Sometimes the screen repainting can be enough of a delay to break co-understanding. This is especially true when using vim navigation. All screen sharing (iChat, Skype video, VNC) seemed to have this issue.

We found that all we were really trying to share was the text editor. With some helpful tips from Linux.com, we were able to get screen with a shared session working. This can be done on any machine where both developers have SSH access. In the following example, John and Pete ssh into a common machine and share a terminal screen session.

User john:

ssh john@common-machine 
screen -S pairprog 
Ctrl-a :multiuser on 
Ctrl-a :acladd pete

User pete:

ssh pete@common-machine 
screen -x john/pairprog

We found it as responsive as any other remote terminal and had the added benefit of not dedicating the developers’ laptops to the task. This is useful for when you’re researching how to solve a problem or looking up API documentation while pairing. Our team found this method of pair programming so useful, we considered it even when in the office. It allows developers to stay in their environments they’re comfortable with and get real work done.

I hope Obie’s post won’t discourage “the masses” from pair programming. Figure out what works for you and make it happen. Pair programming has lots of benefits both to the code base and the participating developers. Similar to TDD, it doesn’t just happen overnight. Pair Programming is a skill that developers need to constantly get better at to succeed.

I wrote it a year ago so that I could eager load polymorphic associations using :include directives in ActiveRecord. This is mostly useful in a search results page.

Adding tests presented an interesting challenge because it is coded as a rails plugin. It’s pretty nasty to test because it uses alias_method_chain to modify the calls to :find and :find_every when a polymorphic exception is thrown.

It isn’t as useful for Rails versions greater than 2.1 because they’ve mostly addressed this issue. However, some queries still throw exception and this plugin tries to correct that. See the README file for more info.

Fork the mojombo.github.com project

It’s a good example site that is under MIT license (except the content itself of course). Added benefit is you don’t have to mess around with the layout just yet.

1. Delete all copyrighted content
2. Change Tom’s information to yours where applicable
3. Change the CNAME to yourdomain.com

Migrate posts from Typo

I had to make some changes to mojombo’s converter for typo 5+. So, grab my version of jekyll or patch your gem install. Here is the diff

With the changes applied, the migration is pretty straight forward.

Modify permalinks and update feedburner

Modify your permalinks in jekyll to match your old typo install so readers don’t lose their way.

Check in all changes to github

You should change your project name to <github-username>.github.com and commit those chages up to github. Also, FYI you need a paid account for CNAMEs to work on github.

Update your domain’s DNS

You need two entries

1. A-record yourdomain.com to 65.74.177.129
2. Cname www.yourdomain.com to yourdomain.com

Add disqus for comments

Since these are static pages, the preferred way to add commenting to your blog is through disqus. Actually, I’ve grown to prefer disqus even if it is self hosted.

1. Add your website at http://disqus.com/add
2. Add the generated javascript to the bottom of your post layout

That should be all you need to get started. I’d recommend changing your layout so your blog doesn’t continue to look like mojombo’s blog. However, this isn’t strictly necessary.

• proxy front end that can scale up as our API use grows and have a caching strategy to reduce the load on our servers
• ability to throttle on a per app (or developer key) basis to anticipate server load
• developer documentation that is easy to update and publish, skinned to look like our site
• ability for developer feedback
• analytics on the usage of the API
• OAuth support

Looking at Mashery’s offering, they seemed like a good fit. That was a month ago. Today, none of those things are fully baked. Nothing of their offering is self-service so everything requires customization. Most tasks run serially and take a minimum of 3-5 business days.

We should have known at the beginning. After the website erred out on purchase attempt, I was assigned an account rep who wanted to set up a conference call. After attempting to explain their cost as a “request per second per developer key”, I counted them out. That type of pricing model wouldn’t work with us mainly because all of our installs of, say, an iPhone app would have the same developer key. That prompted this tweet.

To be fair, the CEO got right back to me (as a side note, I guess it proves Twitter is a good way to get feedback to a company.) He seemed as confused as I was and explained they were changing their pricing model that day. Long story short, we signed up on a monthly basis based on the new, more straightforward pricing scheme (they’ve yet to publish as of this writing.)

One point of contention was OAuth was not a part of their standard package. It was considered an advanced custom feature. It was odd because OAuth is quickly becoming the best practice for accessing user generated content. I would expect a market leader to be driving best practices, not behind on them.

However, OAuth alone would double the monthly fee and require a custom $2500 setup. We decided to implement that ourselves. Again, it isn’t that we couldn’t, we just didn’t want to spend the time. This also complicated matters. Now we’d have to pass valid consumer keys to Mashery so they could still perform their throttling function. This never happened…we weren’t able to get to this discussion before aborting the relationship.

Next pain point was on the skinned development documentation. It took them over a week to “provision” us a portal. And when they did, it wasn’t skinned. After pointing back to the contract, our rep agreed to skin the portal. We sent over a screenshot and was told it would be skinned in 7-10 business days. In short, don’t expect public facing documentation for three weeks after your first monthly payment.

The next hurdle was reporting. Our rep attempted to explain to us their wacked-out URI-based reporting scheme. You had to define which parts of your URL path was important to your calls. Long story short, they don’t support Ruby on Rails RESTful type urls. For example, they couldn’t figure out how to make these different calls for reporting:

• /pictures.xml
• /pictures/39290.xml
• /pictures/39290/comments.xml

The first one is a collection of all pictures. The second is retrieving the single picture with ID 39290. The last one is retrieving the comments attached to the picture 39290. I guess the problem was with ID wildcarding.

Because of this “unusual” URL scheme, we were given a statement of work for $1000 and five business days to implement what amounts to a regular expression in your code. We were told repeatedly that no customer has asked for anything so strange in reporting.

So, we refused to pay the ransom and asked for a refund. They’ve refused the refund. Apparently, they consider us “2 days from success”. We’re out a couple of thousand dollars and a month’s headache for the effort. At least we figured it out early. I would suggest having them prove themselves to you before plunking down any money. At the least, ask for a 30-day guarantee. Don’t let them develop their 1/2 baked product on your dime.

Update 6/18/09

After much back and forth with Mashery on twitter and email they have agreed to refund our money. They were gracious and took the time to understand our frustrations. In the end we have different opinions of how the process should work but I think we both have a better understanding of where each other are coming from.

Create a new local repo:

mkdir myproject 
cd myproject 
git init touch README 
git add . 
git commit -m"first checkin" 
cd .. 

Create a bare tree

git clone --bare myproject myproject.git 
touch myproject.git/git-daemon-export-ok 

Upload to remote machine (in this case a “/src” folder already on the server)

scp -r myproject.git server.domain.com:/src/ 

Check back out from remote repo

rm -rf myproject 
git clone server.domain.com:/src/myproject.git 

You should be all set. Your “master” is now on your remote server. You can branch, push, pull, etc the same as you would on github or similar.

First, you need a fully qualified domain name (FQDN). This can be set in ubuntu by:

sudo /bin/hostname myserver.domain.com 

Next, install postfix and mailutils:

sudo apt-get install postfix mailutils 

Set up your /etc/postfix/main.cf. Here’s what mine looks like:

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = myserver.domain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = myserver.domain.com, myserver, localhost.localdomain, localhost

relayhost = [outgoing.verizon.net]
smtp_connection_cache_destinations = outgoing.verizon.net
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:username@verizon.net:password
smtp_sasl_security_options = noanonymous
default_destination_concurrency_limit = 4
soft_bounce = yes

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

restart postfix and you should be all set

/etc/init.d/postfix restart 

to test from the command line, use mail

myserver> mail email@isp.com
Cc: 
Subject: Testing postfix
test
^D

Two years ago I was bit by the Apple bug. I had been using Linux for the ten years previous and always liked it. I was never a zealot about it the way others in the community were, rather I found it to be good for 80-90% of what I do on a daily basis. Plus, I grew to really like using open source. I was able to contribute where I could and hopefully solve someone else’s issue in exchange for all this great software being maintained.

The nagging part in linux is that other 10% — handling of media and unsupported by vendors. None of it is the fault of Linux developers. Indeed, that is why I care so deeply about creative commons and anti-DCMA issues. However, it is still an issue the average Linux user needs to deal with daily.

Then came the MacBook. It did that other 10% beautifully. Apple actually had deals with the media companies and the promise of all of it “just working” was too much to resist. Besides, it is based on BSD and had a bash shell … maybe it really was the best of both worlds.

Problem is, it doesn’t “just work”. No consumer hardware does, especially laptops. Any vendor telling you otherwise is being dishonest. After joining the Mac community, I began hearing whispers about hardware issues. It seems the biggest problem isn’t that the hardware or software fails, it’s proving to Apple that there is an issue.

Coming from a community with open bug tracking software, open code, and at least knowing someone else is having the issue, I found Apple’s process extremely disturbing. Every issue I’ve had it was like Apple trying to pull a Jedi Mind Trick on me – “You have no issue” they would tell me. The customer is forced to prove beyond a shadow of a doubt that there is, in fact, a problem with their perfect hardware and software. Only then, will they admit there is a problem… but not if they’re actually working on it.

It’s maddening. File a bug, it’ll get closed as a duplicate of another bug you can’t see. Hope you were the first to file! Having hardware issues? Prove it for a “genius”. Don’t want to get charged the $200 repair for the video card? You better mention you know about the recall from nvidia.

And that’s my issue. I know no software is perfect. I wish Apple would stop pretending their software is. Give your users more information on their problem, maybe even an ETA on when it will be fixed. Doesn’t it bother anyone else that their “critical security updates” notes just say “various fixes to improve stability” ?

So the new tag-line for Apple is “It just works, until it doesn’t. Then, good luck”

To be fair, Linux has its share of problems. Actually, probably a lot more than Apple. The difference is how the community investigates and fixes the problems. That’s what I’m more interested in. So I’ll take the additional issues as long as I know they’re being worked on. At worst, I could work on it myself.

Today, I begin the migration back to Linux. It won’t be easy. In the past two years, I’ve bought into the Apple products hook, line, and sinker. Thanks to my great company, I currently have in my possession a MacBook, MacBook Pro, AppleTV, and two iPhones.

The reason I have two laptops is the MacBook Pro’s video card keeps dying. Or it wakes from sleep in my bag and melts. I haven’t had the time to go back to the genius bar and get it fixed again.

I’m pretty sure I’m not Apple’s target market, so this shift shouldn’t bother them much. What should bother them is the new MacBook Pros came out and nobody in the office wanted one. That’s a first. It should scare the hell out of them.

Moving forward – the other MacBook will dual boot OS X and Ubuntu. The AppleTV just got boxee installed on it, making that hardware actually useful. And the iPhone? Well, it looks like I’ll have to jailbreak it. It seems linux can wirelessly sync to that piece of hardware.

For my next hardware purchases when all this Apple hardware dies: Dell laptop with Ubuntu pre-installed, blackberry (or google phone) and a popcorn hour box.

For software, there are two things I need to figure out how to replace – Aperture and iChat screen sharing. I think both can be resolved with some research. We’ve really liked the iChat sharing for pair programming at work and I wouldn’t want to lose that feature.

So, I’m off. Something feels right about it. I’ll probably receive some ridicule at the all-Mac office but it’s the right choice for me. I hope other linux refugees realize they aren’t bound to one vendor for their hardware and software soon.

Turns out this is pretty easy to do in rails. We added the following to our helper file

def suppress_comma_spacing(&block)
  res = capture(&block)
  concat(res.gsub(/\s+,/m, ','), block.binding)
end

then wrapped the code whose output needed modification in a code block in the erb file (trivial example below)

<% suppress_comma_spacing do %>
 <%= link_to "Dick", user_path(dick) %> , <%= link_to "Mary", user_path(mary) %> , and <%= link_to "Jane", user_path(jane) %>
<% end %> 

The result is Dick, Mary, and Jane with the spaces before the commas stripped. Capture allows you to get the processed erb from executing the block. Pretty useful.