What you need to do is open up your vmx file and comment out (disable) the following line:

scsi0:0.mode = "independent-persistent"

Others have also reported finding the following line in their vmx file:

snapshot.disabled = "TRUE"

Share:

# Usage: expect install-tripwire.tcl pass1 pass2 
set PASS1 [lindex $argv 0]
set PASS2 [lindex $argv 1]
 
spawn make install
 
expect "Press ENTER to view the License Agreement."
send "\r"
send "q"
expect "license agreement. \[do not accept\]"
send "accept\r"
expect "Continue with installation? \[y/n\]"
send "y\r"
 
expect "Enter the site keyfile passphrase:"
send "$PASS1\r"
expect "Verify the site keyfile passphrase:"
send "$PASS1\r"
 
expect "Enter the local keyfile passphrase:"
send "$PASS2\r"
expect "Verify the local keyfile passphrase:"
send "$PASS2\r"
 
expect "Please enter your site passphrase:"
send "$PASS1\r"
 
expect "Please enter your site passphrase:"
send "$PASS1\r"

Share:

multiruby is a great way to make sure your ruby code runs on the multitude of ruby versions (it’s part of ZenTest). It doesn’t install macruby by default. Here are instructions on how to set it up.

Since I installed macruby from the package installer my macruby files are in /Library/Frameworks/MacRuby.framework/Versions/0.4/. If your macruby files are somewhere else, adjust accordingly.

First make sure you already have multiruby setup for other versions (don’t proceed if this doesn’t work):

multiruby_setup the_usual


One problem I had with the above command was that I had RUBYOPT set in my .profile. This was calling each of these ruby versions with RUBYOPT=rubygems when trying to install. This won’t work because rubygems is one of the things you’re trying to install. Make sure you unset this variable etc. before trying to setup multiruby.

ln -s /Library/Frameworks/MacRuby.framework/Versions/0.4/usr ~/.multiruby/install/macruby-0.0.4
sudo ln -s ~/.multiruby/install/macruby-0.0.4/bin/macruby ~/.multiruby/install/macruby-0.0.4/bin/ruby
sudo ln -s ~/.multiruby/install/macruby-0.0.4/bin/macgem ~/.multiruby/install/macruby-0.0.4/bin/gem
touch ~/.multiruby/versions/macruby-0.0.4.tar.gz # fake-out

Now try:

multiruby -e "p 1+1"


Share:

Since I use the command-line twitter gem (by John Nunemaker) I miss out on this feature and find myself using echo and wc to make sure I’m not over the limit.

To fix this problem, I’ve written a small, immediate-feedback utility called tweet. It shows you the number of characters typed so far and colorizes them accordingly.

Screenshots:

warning:

over:

Just download this script and save it as tweet somewhere in your $PATH

Share:

for f in `find . -regex ''.*cp.*snippets''` ; do cp bbb.html $f/ ; done

Which returned:

cp: cannot stat `bbb.html': No such file or directory

bbb.html is a symlink and the default behavior of cp (I think) is to try and copy the actual file, which didn’t exist from the current directory. So just adding the -R made cp copy it as a symlink with the final command being:

for f in `find . -regex ''.*cp.*snippets''` ; do cp -R bbb.html $f/ ; done

Share:

If you’re having trouble getting do_mysql to install on Mac OS X. Try the following:

$ locate mysql_config
/usr/local/mysql/bin/mysql_config

The directory /usr/local/mysql above is your mysql directory. Then try to install do_mysql with the following command (split for readability):

$ gem install do_mysql -- \
   --with-mysql-dir="/usr/local/mysql/" \
   --with-mysql-config="/usr/local/mysql/bin/mysql_config"

This solution was found here. I experienced the problem while trying to get merb to run with datamapper on mysql.

Share:

task :one do
  puts "start one"
  sleep 10 * rand
  puts "one done"
end
 
task :two do
  puts "start two"
  sleep 10 * rand
  puts "two done"
end
 
task :three do
  puts "start three"
  sleep 10 * rand
  puts "three done"
end
 
desc "Submit all feed to amazon for SITE"
task :do_all do
  threads = []
  %w{one two three}.each do |number|
    threads << Thread.new(number) do |my_number|
      Rake::Task[my_number].invoke
    end
  end
  threads.each { |thread| thread.join } 
end

Running it gives something like the following:

$ rake do_all
start one
start two
start three
three done
one done
two done

Share:

Organize all files in a given folder by date. This is commonly used to organize a “Downloads” folder. Currently this script will only move files more than 24 hours old. This is to protect against moving a file as it is downloaded.

Motivation

I love SafariStand. One of the features that I love is the sort-downloads-by-date feature. Now that I have moved to Firefox I really miss this feature. I been unable to find a good extension that will sort my downloads in a similar way. This script was written as an simple way to fill that gap.

Setup

I keep a ~/bin directory where I keep simple scripts such as this. Then setup a crontab such as the following:

*/10 * * * * /usr/local/bin/ruby /Users/nathan/bin/organize_folder_by_date.rb /Users/nathan/Desktop/Downloads

Acquiring

It is available on github: here (raw).
or

git clone git://github.com/jashmenn/download_sort.git

Share:

Open up Script Editor and paste this:

on open filelist
	repeat with i in filelist
		do shell script "qlmanage -p '" & POSIX path of i & "' >& /dev/null &"
	end repeat
end open

File > Save As…. Choose “Application” and save it somewhere it won’t move. I choose /Applications/ql.app.

Now simply choose ql.app next time you download a power-point file or set it up in Firefox’s Preferences > Applications.

qlmanage is the command-line tool to open files in Quick Look. By using AppleScript you are able to create this thin “application” that Firefox will trust and give a downloaded file (As opposed to a shell script, which Firefox will not let you choose as a file handler).

Share:

set mirror:order '*.jpg *.gif *.png *.js *.css * */'

This will send first jpg, then gif, then png files etc. This is very handy if you are mirroring an entire website and you want the images to go live before the html does.

Share:

Originally I was using OS X 10.5.4, git version 1.5.3.1, and iTerm or Terminal.app. $TERM=xterm or xterm-color. I have color with PS1, ls, vim and most git tasks. However, git diff (or git show) always screws up the diff by showing the ESC[ characters instead of colors. For instance:

  [nathan@nate ~/s3]$ git show 67d254ec17f
  ESC[33mcommit 67d254ec17fdc507765ddee1feb2a14e5896e79fESC[m

I searched and searched wasn't able to figure out how to fix this. It was suggested on the github forum that I upgrade to git 1.5.6.4. Unfortunately not only did it not fix the color in git diff, it broke the color in git status which was working previously.

After about a week of poking around on and off I discovered that the problem was not git, but my GIT_PAGER which is more. If I tried GIT_PAGER=cat git-diff then the color output just fine. less and more use the same environment variable LESS (man less for details). And less was outputting the colors as raw escape codes.

man less shows that the option -R is defined as follows:

       -R or --RAW-CONTROL-CHARS
              Like  -r,  but  only  ANSI "color" escape
              sequences are output in "raw" form.

That would do it.

After perusing the man page for a while I settled on adding this to my
~/.profile:

  export LESS="-erX"

At the end of the day, this tip is really about less and how it interprets colors and probably has little to do with git. Even so, I only found this odd behavior while using git. Hopefully this post will help someone who is having similar issues.

As a side note, below is an example of how to configure your colors for git-diff and other commands.

[user]
    name = Your Name
    email = y...@yours.com
[color]
    branch = auto
    status = auto
    diff = auto
[color "diff"]
    meta = yellow
    frag = cyan
    old = red
    new = green
[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green
[color "status"]
    added = yellow
    changed = green
    untracked = cyan
[alias]
    st = status
    ci = commit
    co = checkout
    br = branch

Share:

• Ola Bini – jruby core developer
• Jeremy Kemper – 37signals
• Ezra Zygmuntowicz – EngineYard

Each of these guys are Ruby-Rock-Stars and they are way smarter than I am. The content of what they presented was, in every case, phenomenal. They are some of the best programmers in our community and if they can’t give a presentation without typos and mistakes I can almost guarantee that I (you) won’t be able to either. When you get in front of 300 people, start typing, start talking, and realize you’re under the pressure of time (and the crowd) it changes your ability to focus on any one task and it is very hard to not make mistakes. My theory is that one can present a live-like demonstration with no loss of effectiveness.

The most obvious way to do a live-like demonstration is by recording a screencast. You could also use AppleScript or library like castanaut (if you are on a mac). The app I’d like to recommend today is ttyrec . It’s a great little command-line app (it compiles flawlessly on my OS X 10.4) and it records the output of a shell session and can play it back like you are typing in real time. I see two major benefits to this:

• You can’t make mistakes. It’s recorded and it’s storing the output all into a text file. This means that if the network fritzes out when you’re on stage it doesn’t matter. Network outages, ill-timed bugs, etc. become irrelevant because the commands are not actually run at playback time (the stderr/stdout stream is saved into a text file).
• You can talk while you’re playing the demo. They do this in TV all the time (think Friends). In a scene where actors play video games they don’t actually play the game and act at the same time. The video games are recorded so the actor can focus on acting. When your computer is playing-back the work you’ve prepared before hand you can focus on talking while the “typing” is happening on the screen. You don’t have to do the mental context-switching of talking and typing simultaneously which causes mistakes that cost you (and maybe more importantly, your audience) time.

You may say “Well, I don’t want to do a recording, I want my demo to be live”. Here’s my view on that: Most people don’t care if your demo is actually live. When you’re on stage and what you’re showing is prepared it’s assumed to be in the perfect environment because you’ve been testing and developing in that exact environment. Even if your demo is truly live it still seems “contrived” in that we, the viewer, can never actually see all the pre-work, installing, compiling, back end etc. that was prepared behind the scenes. As Josh Susser pointed out: “keep in mind Lansford’s Corollary to Clarke’s Third Law: ‘Any sufficiently advanced technology is indistinguishable from a rigged demo.’”

I believe that recording your shell with ttyrec or similar is exactly as effective as a live demo. If I, as a listener, am interested in your project I’ll be the same amount of convinced to download/try/buy even if your demo is recorded. In fact, I’ll be a lot more convinced to try it out if you play something recorded that runs perfectly as opposed to a system that is so complicated or buggy that even the author is having problems using it.

So please record your “live coding” before hand. Your audience will thank you, you’ll avoid embarrassment, and you’ll be more effective for it

UPDATE I removed Yehuda Katz from the list of non-recorded presenters. My apologies go out to Yehuda who pointed out that he did record his presentation before-hand.

Share:

Open up ~/.screenrc add the following lines:

  multiuser on
  acladd nathan # change to your username here

In terminal one start a screen session. Then log in as the same user on terminal two and type screen -x. Now either user can control and see real time what is going on in the tty. It is possible to do this across users, I believe. See your local man page.

They use this in combination with audio/video chat (Skype or iChat). This way they can see facial expressions, ask for control of the keyboard etc. Jim and co. have keywords for passing control, I believe they are “drive?” and “release.” The person who wants to take over says “drive?” and they are allowed to use the keyboard iff the other person says “release.”Seems like a simple, but powerful idea.

UPDATE Jim pointed out that they use the terms “tag” and “yield”. Thanks Jim!

Share:

Understanding commits is the key to grokking Git. You’ll know you have reached the Zen plateau of branching wisdom when your mind contains only commit topologies, leaving behind the confusion of branches, tags, local and remote repositories, etc.

Even after reading his pdf it took me two days for this idea to sink in. I finally had my “ah-ha!-moment” after I poked around in the .git/refs folder for a while.

Git Pieces: Taken from John Wiegley’s article, “Git from the Bottom Up”

I think I resisted learning the git internals for a while because I didn’t want to understand it I just wanted to use it. The problem was I wanted to use it like svn and git requires a mental paradigm shift. After reading John’s article I’ve come to realize once again that there are no shortcuts to progress and often the quickest way to learn is to first take the time to understand.

I’d highly recommend that anyone that still working on “grokking git” should take the 30 minutes required to read John’s article.

Share:

Take a look at your logs: are you performing over 10 database calls per request? You need to fix this. Are you performing over 90? You’re a dumba**.

Today viewed the logs of a rails application I am writing. To calculate one particular page I was performing 31,211 SELECT requests and the page took 1m7.091s to generate. Ouch.

After an hour of tweaking, optimizing queries, and piggy-backing some attributes I was able to get down to 9,839 queries and the page rendered in 0m16.958s. While this may be respectable in terms of improvment, but atrocious according to Courtenay’s benchmark. (I think they have a word for systems that take over 9 thousand queries to generate a single page, but I won’t repeat it here.)

Fortunately, caching the entire page makes sense functionally. However, one problem with Rails’ built-in caching is that before the page is cached the first person to hit this page will be forced wait 17 seconds for the page to render (assuming no further optimization). In the case of a high amount of traffic, hundreds of visitors to the site will pile up and many will be dropped. It’s the dreaded cache-gap.

Steve Conover at Pivitoal Labs has a great technique for dealing with this kind of issue that he calls the symlink trick. A variation on Steve’s idea goes like this:

• Symlink index.html to index.html.current.
• When index.html.current is out of date, generate index.html.new
• Have cron check the cache every 2 minutes and move index.html.new over index.html.current

Because *nix mv is atomic there is no gap where the cached page is deleted and then requests are waiting for the page to be regenerated. Below is a diagram of the process.

The great thing is that this caching technique is general and can be applied to any web application, not just Rails.

Share: