ls, colors, and Terminal.app
This isn’t a Ruby thing but many of us spend a lot of time in Terminal.app, and I suspect few of you have taken the time to both changing your LSCOLORS, the setting which affects what colors ls uses when in color mode.
Enable Colors in ls
In order for ls to use colors at all, you need to set up an alias to turn colors on. To do this, open (or create) .profile file in your home directory using your favorite text editor and add:
alias ls="ls -G"
Now open a new Terminal window and type ls. You will see colors, hurray!
Make Colors Linux-like
If you’re used to Linux-like colors, you will appreciate this setting. This is what I use and it works particularly well on dark Terminal backgrounds (I use the “Pro” theme). I also check off “Use bright colors for bold text” under Terminal > Preferences > Settings. Again, add this to your .profile:
export LSCOLORS="ExGxBxDxCxEgEdxbxgxcxd"
Customize Your Colors
If you’re interested in fully customizing your LSCOLORS variable, you’ll find more below the fold.
The values in LSCOLORS are codes corresponding to different colors for different types of files. The letter you use indicates which color to use, and the position in the string indicates what type of file should be that color. Each color comes in pairs – a foreground color and a background color. Here is a list of color values:
- a = black
- b = red
- c = green
- d = brown
- e = blue
- f = magenta
- g = cyan
- h = grey
- A = dark grey
- B = bold red
- C = bold green
- D = yellow
- E = bold blue
- F = magenta
- G = cyan
- H = white
- x = default
And here is a list of the positions in LSCOLORS:
- directory
- symbolic link
- socket
- pipe
- executable
- block device
- character device
- executable with setuid set
- executable with setguid set
- directory writable by others, with sticky bit
- directory writable by others, without sticky bit
The default is “exfxcxdxbxegedabagacad”, which indicates blue foreground with default background for directories, magenta foreground with default background for symbolic links, etc.
Interview on the Ruby on Rails podcast.
The interview I did with the incredibly gracious and awesome Geoffrey Grosenbach (of Peepcasts) on the official Ruby on Rails podcast just went up.
I talk a little bit about consulting at Norbauer Inc, a bit about RubyRags, and I spend a bit of time kicking social networks in the nuts.
Incidentally, I’m proud to announce that we’re now selling Peepcode shirts at RubyRags:
Alternative Ruby Implementations
Sorry to just link drop on ya’ll, but if you haven’t seen it, Charles Nutter of the JRuby team has published a writeup titled Promise and Perils for Alternative Ruby Impls. It provides an excellent analysis of 1.8, 1.9, JRuby, Rubinius, and the other Ruby interpreter projects out there, if only slightly biased for JRuby (understandably). If you have an interest in the future of Ruby, it is a recommended read.
Rails 2.0 development finally meets Web 2.0
I know I am late to the show, but I’d just like to say it is about time that Rails move off of Trac – with the move to Lighthouse and Github, Rails development itself is now hosted on awesome Rails-based services. I know such migrations are not easy for such a large project so I just want to say thanks to the Rails team, and nice choices!
Strange analogy
Creating software is like eating a grapefruit (Randall Munroe’s favorite fruit). Sure, you can rush through it and you’ll get some enjoyment out of the grapefruit bits, but if you take your time and patience, you will get much more out of it. Like all things, you reap what you sow.
Gitsplosion
So Git has this charming habit of leaving directories intact when you use it to delete their content. If you try to delete, say, vendor/rails, it will therefore leave a barren ghost-town of EDGE directories intact.
This will cause the following, not-particularly-elucidating error whenever you try to do anything:
(in /Users/ryan/Sites/app_name)
rake aborted!
no such file to load -- /blah/blah/lib/initializer
/Users/ryan/Sites/app_name/rakefile:4
(See full trace by running task with --trace)
The solution is just a simple, friendly:
rm -rf vendor/rails
Then you’ll be able to freeze again, and whatnot.
UPDATE I have submitted a patch to Rails to make it less dumb about this (and actually check that Rails really exists rather than just checking for its directories.) If you think this is a worthwhile patch, please go put a +1 in the ticket comments.
Then once we can set it to “Verified,” maybe it’ll be accepted in three years, just in time for Git to be supplanted by some other new nerd bauble.
Yet another Ruby framework and HTTP adapter
It’s an exciting time to be Ruby or Rails developer as there are so many new and exciting things going on – in fact, it’s a lot to keep tabs on. Let’s look at two issues: Ruby web frameworks and HTTP adapters.
So, web frameworks, some of these you’ve probably heard of:
- Ruby on Rails – You’ve probably heard of this one.
- Camping has been around for a while, and aims to be tiny and simple – great when you’re only building a few pages. Developed by the infamous why.
- Merb was created by Ezra, which now has many of the core Rails features, but less of the frills. It’s fast and, best of all, its thread-safe.
But, oh, there are so many more:
- Nitro – Been around a while now, but development stalled for a year or two.
- Ruby Waves, which claims to be highly flexible.
- Wuby, a tiny server+framework, which serves RHTML files, in a manner similar to PHP.
- Sinatra, a REST-centric framework which uses a DSL to make life simpler.
- Ramaze, which is also very flexible, supporting a variety of ORMs, template engines, HTTP adapters, etc.
- Mack is brand new, claiming to be highly modular and agile, as well as speedy. Their site is down but their documentation is up.
- Maveric
- Vintage
- Cerise – Not recently maintained (2006).
- IOWA – Not recently maintained (2004).
I’m sure I still missed some. Moving on the HTTP adapters – these are the likes of WEBrick and Mongrel. It’s good to keep up on these as they can often mean a boost in performance for your app, often regardless of your framework, thanks to the common interface provided by the Rack library.
- Ebb is the newest to the show, touting fantastic performance as most of it is written in C. It can be a little tough to set up. It has support for Rails; for other frameworks, you’ll have to roll your own interface.
- Thin is quickly becoming the defacto standard (at least until ebb is further along)
- Swiftiply and Evented Mongrel was the first to improve Mongrel’s performance.
- Mongrel started it all.
- Fuzed allows your Rails app to run with Yaws.
- Passenger is “mod_rails” for Apache, which could be a big news. They are also working on Ruby Enterprise Edition, which will be launched soon.
And you have already learned and adopted git, right? Can’t fall behind the times…
git: revert (reset) a single file
This one is hard to find out there so here it is. If you have an uncommitted change (its only in your working copy) that you wish to revert (in SVN terms) to the copy in your latest commit, do the following:
git checkout filename
This will checkout the file from HEAD, overwriting your change. This command is also used to checkout branches, and you could happen to have a file with the same name as a branch. All is not lost, you will simply need to type:
git checkout -- filename
You can also do this with files from other branches, and such. man git-checkout has the details.
The rest of the Internet will tell you to use git reset --hard, but this resets all uncommitted changes you’ve made in your working copy. Type this with care.
Generating access keys
This is a somewhat obscure but very efficient way to generate access keys. Look ma, no loops!
Array.new(16) { rand(256) }.pack('C*').unpack('H*').first
This will generate a 32-length key, like b3512f4972d314da94380e1a70e6814a.
This may look strange unless you’ve used Array.new, Array#pack, and String#unpack many times in the past. In the gaming world, I tended to deal with binary data on a regular basis, so pack and unpack became commonly-used weapons in my repertoire. They allow you to operate on binary data – pack creates binary data (stored in a regular string) from an array of Ruby objects, and unpack takes binary data and creates Ruby objects in an array. If you think about it, you are dealing with binary data here: you’re creating a random 128-bit (16-byte) key which you want in hex-format, so using pack and unpack do make sense. The parameters (C* and H*, in this case), are formats which indicate how to process the data.
Very cool cats may want to create more-compact Base64 keys. Be aware that Base64 is case sensitive:
[ Array.new(16) { rand(256) }.pack('C*') ].pack('m').chop
This generates keys like Gv5CJ68ptOZKVRvAFdzGpg==.
New RubyRags shirt
I’m excited to announce a new fantastical RubyRags design: The Ruby City.
It’ll be in stock and shipping in mid- to late April.
You can join the waiting list or read more at the RubyRags site.
