Cacheable Flash and jQuery

I’ve been using this great plugin on Pledgie called Cacheable Flash to show flash messages on page cached pages.

A few weeks ago, we implemented page caching on the campaign landing pages, because that is the first page one sees when they click on a badge in the wild, and so I wanted to make sure there was no delay in delivering that content to the user.

The only bump in the road in implementing Cacheable Flash was that it relies on Prototype. We don’t use Prototype on Pledgie, instead we prefer jQuery.

So I forked Cacheable Flash on GitHub and ported it from Prototype to jQuery. For anyone that wants to use Cacheable Flash with jQuery, wait no longer, clone this repo:

1
$ git clone git://github.com/up_the_irons/cacheable-flash.git

… and enjoy!

Fix for Noisy Fan on the ThinkPad X300

One thing that got annoying with my new ThinkPad X300 was the fan seemed to run at full speed almost all the time. I’m running Ubuntu 8.04 Hardy.

Once again, ThinkWiki came to the rescue in their article on How to control the fan speed.

Using my new found knowledge, I wrote a little script that made it easy to control the fan speed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/sh                           
#
# Control fan on a ThinkPad.
#
# Be sure to add the following to /etc/modprobe.d/options:
#
#    options thinkpad_acpi fan_control=1
#
# and reboot, before using this script.

usage() {
  echo "$0 <level> (<level> is 0-7, auto, disengaged, full-speed)"
  exit
}

if [ -z "$1" ]; then
  usage
  exit
fi

sudo sh -c "echo level $1 > /proc/acpi/ibm/fan"

Be sure to modify your /etc/modprobe.d/options as specified in the comments.

Then just run:

1
$ ./fan.sh 2

for a much quieter fan (low speed) that doesn’t seem to sacrifice cooling when coding (vi, Firefox, mutt, and Gnome is what I run mainly).

You’ll want to switch it back to ‘auto’ if you’re gonna do anything processor intensive.

Enjoy!

Programming for Pain

Try this “programming exercise”:

1
2
3
4
5
6
7
[garry@garry-thinkpad] ~ (master) $ irb
irb(main):001:0> i = 0
=> 0
irb(main):002:0> i += 1; r = rand(10); puts "r = #{r}, i = #{i}"
r = 7, i = 1
=> nil
irb(main):003:0>

See the value of “r”? Drop down and do that many push-ups.

Pop back up and hit your favorite key for repeating the last command:

1
2
3
4
irb(main):003:0> i += 1; r = rand(10); puts "r = #{r}, i = #{i}"
r = 3, i = 2
=> nil
irb(main):004:0>

That’s right, drop and do “r” more push-ups.

If you get a “0”, you get to rest for 1 minute.

When “i” reaches 52, you’re done.

This is a variation of “prison push-ups” that I tried because I didn’t have a deck of cards.

This is quite a challenging workout. It might sound easy, depending on how fit you are, but wait until “i” reaches around 20 or so. :)

Homework: Wrap this in a nice script so you just press a key to get the next count, and have it record your time.

Amazon S3 and “Connection Reset by Peer”

I’ve been doing a lot of S3 work lately, mainly uploading very large files, between 100MB to 5GB. On a box that was responsible for uploading backups to S3, I would consistently get errors like:

1
2
Connection reset: Connection reset by peer
99 retries left

(Using a Ruby library)

or

1
2
...
socket.error: (104, 'Connection reset by peer')

(Using a Python library)

or it would just plain stop (silently fail) using a bash-only library (but I could see in tcpdump, the connection was reset).

This was driving me nuts!

So after looking at enough tcpdump’s to make my eyes bleed, and contacting Amazon (they were no help), I finally determined the cause of the problem to be a combination of:

  • TCP Window Scaling
  • Linux kernels 2.6.17 or newer

Basically, as I understand it, Linux kernels 2.6.17+ increased the maximum size of the TCP window/buffer, and this started to cause other gear to wig out, if it couldn’t handle sufficiently large TCP windows. The gear would reset the connection, and we see this as a “Connection reset by peer” message.

The fix for this is easy peasy, but it’ll slow your maximum throughput (this is why the Linux kernel guys decided to up the default in the first place, give people faster downloads, why not). Put the following in /etc/sysctl.conf:

1
2
3
# Workaround for TCP Window Scaling bugs in other ppl's equipment:
net.ipv4.tcp_wmem = 4096 16384 512000
net.ipv4.tcp_rmem = 4096 87380 512000

Then run:

1
$ sudo sysctl -p

The last number in that group of three is the important one. If you’re not getting any resets, increase it and your uploads/downloads will be faster. If you are getting resets, decrease it and it’ll make the resets go away, but your throughput will be slower now.

Your location of /etc/sysctl.conf might be different (I’m on Ubuntu). But you get the idea.

I should note that this problem doesn’t just happen with S3, but a LOT of other sites as well. It’s actually been well documented outside of the realm of S3, and if you want more info, refer to:

Hopefully this post will save someone from doing too much of what I did.

Keyspan USB-to-Serial Adapter Support in Ubuntu Linux

Today I wanted to use my Keyspan USB-to-Serial adapter on my Ubuntu (gutsy) box. Unfortunately, Ubuntu doesn’t ship with a driver for this because of some licensing restrictions. So after trying a few things the hard way, I found out an easy way to build the drivers.

Follow these steps.

Note: Wherever I use “amd64” in the below examples you’ll need to replace with your architecture if you’re not on 64-bit Intel or AMD.

Grab the kernel source package:

1
2
3
4
5
# Use whatever path you like
cd ~/debian-src/kernel

apt-get source linux-image-2.6.22-14-generic
cd linux-source-2.6.22-2.6.22/

If you don’t already have the Ubuntu tools for building packages, you’ll need to run:

1
sudo apt-get build-dep linux-image-2.6.22-14-generic

Now edit the following file:

1
vi debian/config/amd64/config

Add the following under the line that reads CONFIG_USB_SERIAL_KEYSPAN_PDA=m:

1
2
3
4
5
6
7
8
9
10
11
12
13
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y

Rebuild the kernel like so:

1
fakeroot debian/rules binary-generic

And now install it:

1
2
cd ..
sudo dpkg -i linux-image-2.6.22-14-generic_2.6.22-14.52_amd64.deb linux-headers-2.6.22-14-generic_2.6.22-14.52_amd64.deb linux-image-debug-2.6.22-14-generic_2.6.22-14.52_amd64.deb

You should now be able to insert a Keyspan USB-to-Serial adapter into the USB port and it’ll be recognized as /dev/ttyUSB0. Check dmesg for any errors.

Credit Card CLI Tools

I just uploaded a set of tools for processing credit cards to GitHub. GitHub is pretty awesome BTW.

All you need is a PayPal Business or Premeir account.

Most will not want to do this kind of thing on the command line, and I understand. I wrote these scripts just to be able to interface with my legacy system that I wrote in 1999 for use with CyberCash (and later Verisign PayFlow Pro). But I figured maybe there’s a few others out there that might like this.

Here’s a couple neat things you can do:

1
2
3
4
5
6
7
8
9
10
Example $1.00 charge:

  $ ./charge.rb 1.00 4111111111111111 02/2012

Example $1.00 refund:

  $ ./refund.rb 1.00 2TL24251DY409204F

The second argument in the above example is the Auth ID of the original 
transaction.

You’ll get back a YAML formatted version of PayPal’s response to stdout.

I use ActiveMerchant to do all the heavy lifting. AM is wonderfully easy to use, those guys did a really good job.

For more info, see the repo and README here: http://github.com/up_the_irons/credit_card_tools/tree/master