April 30, 2007
Reboot
I apologize if I've been distant lately; right now I'm in the process of rebooting my life.
Friday will be my last day with IBM.
Over the next few weeks I'll be relocating to the Bay Area to work for Google.
In
General
Posted at 11:25 PM | Permanent link
|
Comments (6)
February 07, 2007
Jazz.net goes live
If you'd like a peek at what I've been up to at work for the past eight months, head over to jazz.net, which just went live.
The details are still kinda sketchy, but expect more real soon now :)
In
Technology and Software
Posted at 11:44 PM | Permanent link
January 18, 2007
Eclipse is a dead system
(DON'T PANIC! I probably don't mean what you think I mean.)
On a long enough timeline, the survival rate for everyone drops to zero.
Steve Yegge has a thought-provoking essay on living systems vs. dead systems, in essence: systems that can be modified at runtime vs. systems that you have to stop (kill) first to modify.
In this context Eclipse is a "dead system" (or "hardware" as Stevey says). And this makes me sad :(
In fact, it's saddened me for a while, though I've never framed the issue in these terms.
Even though Eclipse has a world-class extension system, we have to go through an onerous process of launching and relaunching Eclipse instances to make the slightest change to a plugin.
In contrast, a "living" system like Emacs doesn't have this problem. In Emacs we can evaluate s-expression, set variables, rewrite functions, and swap code on the fly without having to relaunch - which is why writing Emacs extensions is an order of magnitude easier (and more fun) than writing Eclipse extensions.
Stevey also draws a parallel between how long a system can stay running without reboot, and how long people will continue to use the system.
*shrug*
I think it has more to do with how close your system gets to hitting the best solutions to the problems people are trying to solve on any given day. But here's the thing: the problems of today aren't necessarily the problems of tomorrow, nor the problems of ten years from now.
The more malleable your system is, the better its chance of solving the problems of 2007, and 2008, and 2017, and 2027. And as it happens, systems that can be modified without a reboot are much easier to modify and far more malleable than systems that can't.
Eclipse has many advantages over Emacs (mostly in terms of gooeyness), but as ugly as Emacs looks on the outside, it's definitely the more malleable of the two. So, if I had to choose pick which one is more likely to be around in 100 years, my money would be on Emacs. And if history is any guide, that's probably not a bad bet.
UPDATE:
Hehe, as Bill points out in the comments, I do feel like kind of a bastard for writing this post (especially the inflammatory title). But my aim isn't to disparage Eclipse. I love Eclipse. It's a great platform, and it's very good at what it does.
And no... it's certainly not "dying" :)
My aim is to point out that there are other kinds of extensibility out there that we don't typically get with Eclipse... at least not right now, and it's the kind of extensibility I'd very much like to see.
And just for full disclosure, I work for the company that originally founded the Eclipse project. All views expressed here are my own and not those of my employer.
In
Technology and Software
Posted at 06:05 PM | Permanent link
January 16, 2007
Raleigh bloggers meetup tonight @ Helios Coffee
Though it's been a while since I've advertised it here, the Raleigh area blog meetup is still going strong.
We meet twice a month: the first and third Tuesday, 6:30PM at the Helios Coffee Company.
Details at the wiki.
Tonight will be our first meetup of the year. If you live in Raleigh or around Raleigh, please join us! I'd love to meet you in person.
(Dave even has Helios photos)
In
Blogging
Posted at 09:00 AM | Permanent link
links for 2007-01-16
-
"I was able to create a page that was hosted on a google.com domain, which is something that should never be allowed to happen."
-
A great "nutshell" overview of writing a RESTful web service.
-
"Justin Timberlake is not a guilty pleasure. Putting oven cleaner in your daughter's Similac is a guilty pleasure, or smearing birdseed on your balls and visiting an aviary."
-
Yay for Darwin :D
-
Why You Shouldn't Leave A Gallon Of Paint With Unsupervised Toddlers
-
It can be clearly seen that Communist’s coup was so successfull due to the help of time travelers who had come from the future equipped with PDAs, cell phones and laptops.
-
This is a blog post I've been wanting to write for a while.
Posted at 12:29 AM | Permanent link
January 15, 2007
How to install bzr on Dreamhost
Bazaar or bzr is a Python-based source code management system that I've noticed is becoming increasingly popular amongst small open-source projects.
Right now I'm not sure what advantages bzr might have over other SCM systems such as Subversion (I suspect it's more light-weight), but it's handy to have when you want to grab the source for a project like Planet Venus.
Here's how I installed bzr on my Dreamhost shell account.
(note: There's not anything special here. This is all pretty standard Unix tarball installation fair. In fact, there's little here that isn't already in the bzr installation guide. I'm providing this as a confidence cushion for other Dreamhost users.)
Fetch it
Downloads of bzr are available here: http://bazaar-vcs.org/Download
Fetch the tarball install into a directory of your choice:
~$ cd ~/incoming
~/incoming$ wget http://bazaar-vcs.org/releases/src/bzr-0.13.tar.gz
Unzip it
~/incoming$ tar -zxvf bzr-0.13.tar.gz
Install it
~/incoming$ cd bzr-0.13
~/incoming/bzr-0.13$ python2.4 setup.py install --home ~
No problem...
Adjust environmental variables
... except one hiccup when we try to run bzr:
$ bzr
bzr: ERROR: Couldn't import bzrlib and dependencies.
Please check bzrlib is on your PYTHONPATH.
Traceback (most recent call last):
File "/home/joshstaiger/bin/bzr", line 62, in ?
import bzrlib
ImportError: No module named bzrlib
Because we installed bzr in our home directory, the Python code behind bzr is living in a nonstandard location that Python can't see. We add this location to our Python library path by setting the PYTHONPATH environmental variable in our .bashrc.
Modify .bashrc as follows:
echo "export PYTHONPATH=/home/joshstaiger/lib/python" >> ~/.bashrc
(replace "joshstaiger" with your shell login name)
We'll also want the bzr manual to be in our MANPATH if it isn't already, so we can read about bzr in our spare time instead of picking up women:
echo 'export MANPATH=$MANPATH:/home/joshstaiger/man' >> ~/.bashrc
Source .bashrc (or relogin) to pick up our changes:
. ~/.bashrc
Run it
And we're set:
~$ bzr
Bazaar -- a free distributed version-control tool
http://bazaar-vcs.org/
Basic commands:
bzr init makes this directory a versioned branch
bzr branch make a copy of another branch
bzr add make files or directories versioned
bzr ignore ignore a file or pattern
bzr mv move or rename a versioned file
bzr status summarize changes in working copy
bzr diff show detailed diffs
bzr merge pull in changes from another branch
bzr commit save some or all changes
bzr log show history of changes
bzr check validate storage
bzr help init more help on e.g. init command
bzr help commands list all commands
bzr help topics list all help topics
In
Technology and Software
Posted at 10:54 PM | Permanent link
January 13, 2007
links for 2007-01-13
-
ecdysis: a lisp-like syntax for python
-
"Although this code is ugly, writing it gave me a feel for the real power of a language like lisp."
-
all Tony needed to do was make a user who’s logged into their Google Account visit a page of his, which happened to be on a “trustworthy” google.com sub-domain
-
WebKit now has some very basic support for multiple columns from CSS3.
-
The iPhone has given the nerd community it's hardest collective wood since Princess Leia wore a bronze bikini.
-
Ripped from Andy Riley's excellent "The Book of Bunny Suicides" and "Return of the Bunny Suicides".
In
General
Posted at 11:29 PM | Permanent link
January 12, 2007
The iPhone is NOT a platform
Ok, I was wrong.
Looks like they will be fighting us every step of the way.
*shrug*
Steve just lost my willingness to give him $599 and put my balls in a vice grip with his carrier (which I otherwise would have done gladly, just to play in the new sandbox).
I will, however, continue to write webapps that incidentally work well on his phone, safe in the knowledge they'll no longer have to be crippled to be mobile.
In
Technology and Software
Posted at 03:51 AM | Permanent link
January 09, 2007
The iPhone as a platform
Tonight, every nerd I know is salivating over the iPhone.
Obviously people are orgasmic over the sexyness: the form-factor, the fluid touch-screen, the (for serious!) smart calling software, the media apps, and the internet connectivity.
But I think the real story here is we finally have a real platform for mobile application development, complete with real OS, real apis, and a real web browser capable of running real web applications - all delivered by a company that isn't going to fight us every step of the way.
And the sexyness ensures it's going to be very popular.
It almost sounds like the mobile platform we've been waiting for for the past ten years!
This is going to be big :)
In
Technology and Software
Posted at 09:47 PM | Permanent link
December 29, 2006
Metaprogramming method closures in Ruby
In my previous post, Of Closures, methods, procs, scope, and Ruby, I discussed how blocks and procs are closures in Ruby while methods are not.
To review, this won't work:
class MyClass
@friend
hello_string = "Hello"
def initialize
@friend = "Kitty"
end
def say_hello
puts hello_string + " " + @friend # Bzzt! hello_string is not in scope
end
end
my_object = MyClass.new
my_object.say_hello # Bzzt!
And neither will this (at the toplevel):
hello_string = "Hello, world!"
def say_hello
puts hello_string # Bzzt! hello_string is not in scope
end
say_hello # Bzzt!
In response Kurt hypothesized we could get method closures in Ruby with a bit of metaprogramming.
And he's right.
As Bryce points out, Ruby's Module class has a private method nammed define_method that defines a new method given a symbol representing its name, and a block representing its body.
Because the second parameter is a block, and blocks can be closures, this gives us the key to defining method closures.
Within the context of a class definition:
class MyClass
@friend
hello_string = "Hello"
def initialize
@friend = "Kitty"
end
define_method(:say_hello) { puts hello_string + " " + @friend }
end
my_object = MyClass.new
my_object.say_hello # Hello Kitty
Yay!
But suppose we want to define one-off methods from the top-level instead.
Because define_method is private, normally we wouldn't be able to call it outside a class definition, but we can get around this using the send hack.
Let's define a convenience method:
def lexdef(method_symbol, &block)
self.class.send :define_method, method_symbol, &block
end
And now we can define method closures from the toplevel:
hello_string = "Hello"
lexdef :say_hello do |friend|
puts hello_string + " " + friend
end
say_hello "Kitty" # Hello Kitty
Voilà! An unobtrusive syntax for defining method closures!
I like it :)
As of Ruby 1.8, blocks don't yet support Ruby's first-class syntax for receiving block arguments. So this won't work:
hello_string = "Hello"
lexdef :say_hello do |friend, &formalize| # Bzzt! Syntax error
puts hello_string + " " + yield(friend)
end
say_hello("Kitty") { |friend| "Ms. " + friend }
But word on the street is &block arguments to blocks will be supported in Ruby 1.9.
In
Technology and Software
Posted at 06:34 PM | Permanent link
December 28, 2006
The Ruby send hack: how to gain access to an object's privates
I stumbled across an interesting Ruby hack that doesn't seem to be written down anywhere.
It turns out that private methods in Ruby aren't entirely private, and with a bit of indirection you can gain access to them as though they were public methods.
In Ruby 1.8 all we have to do is use the Object#send method.
To demonstrate:
class MyClass
private
def say_hello(name)
puts "Let's go back to my place, #{name}."
end
end
my_object = MyClass.new
So we get smacked if we try:
> my_object.say_hello
Nomethoderror: private method `say_hello' called for #<MyClass:0x820b4>
from (irb):8
from :0
but instead:
> my_object.send :say_hello, "world"
Let's go back to my place, world.
Touché!
Now, honestly, this strikes me as odd. Conceptually, I don't see why send should function differently from an ordinary method call with respect to access control.
The rubydoc for send says nothing of this, and there is some debate on the mailinglist as to whether Ruby 1.9's send will maintain this behavior.
But for now this can be very useful if you disagree with a class designer's method access choices.
In
Technology and Software
Posted at 01:06 PM | Permanent link
December 26, 2006
Of closures, methods, procs, scope, and Ruby
One thing I hate about Ruby is that Ruby methods aren't closures.
For instance, this blows up:
hello_string = "Hello, world!\n"
def say_hello
puts hello_string # bzzt! hello_string isn't in scope
end
say_hello # bzzt!
Which is a little odd because Ruby does support closures on procs:
hello_string = "Hello, world!\n"
say_hello = Proc.new do
puts hello_string
end
say_hello.call # Hello, world!
It kinda sucks that every time I want to create a closure I'm forced to use the less succinct ".call" syntax.
So why can procs be closures while methods cannot?
After a bit of thinking I realized this comes down to a design tradeoff on whether or not we have to type "self" or "this" all over the place when writing methods as we do in Python and JavaScript.
In Ruby we don't have to do this, and Ruby accomplishes this by making procs and methods two different things with different scoping rules.
Proc bodies have a lexical scope like functions in Lisp and JavaScript, meaning that when Ruby encounters a free variable inside a proc body, its value is resolved within the context the proc was defined. This is what makes closures possible.
Methods are different, however. A method's context is the object to which they are bound. When Ruby encounters a free variable inside a method body, it assumes the variable refers to another method on the object, and this is what saves us from having to prefix same-object methods with "this" or "self".
To demonstrate:
irb(main):171:0> hello_string = "Hello, world!"
=> "Hello, world!"
irb(main):172:0> def say_hello
irb(main):173:1> puts hello_string
irb(main):174:1> end
=> nil
irb(main):175:0> say_hello
NameError: undefined local variable or method `hello_string' for #
from (irb):173:in `say_hello'
from (irb):175
from :0
irb(main):176:0> def hello_string
irb(main):177:1> "Hello, world!"
irb(main):178:1> end
=> nil
irb(main):179:0> say_hello
Hello, world!
=> nil
Personally, I'm not sure I like this tradeoff.
Procs and methods are conceptually very similar. They are both composed of a list of arguments, a block of code, and a context in which the block is evaluated. I'm not sure they should be different things.
The way I see it, a method should just be a special case of proc that happens to have an implicit "self" parameter. In this case methods would inherit the proc scoping rules and therefore could be used as closures.
If this means we have to be verbose and type "self" to call other methods on the same object, I'm fine with that.
And in fact, this is how things work in JavaScript:
var helloString = "Hello";
var myObject = {
friend: "Kitty",
sayHello: function() {
print(helloString + " " + this.friend);
}
};
myObject.sayHello(); // Hello Kitty
Matz clearly recognizes that there are issues with Ruby's current scoping implementation, so maybe this is one of them.
But, hey, this kind of tradeoff may just be a Rubyish thing to do, and I probably dig closures more than most.
In
Technology and Software
Posted at 05:54 PM | Permanent link
|
Comments (3)
December 20, 2006
Real life search
I love how whenever I lose something in my house, my first instinct is:
Oh, no problem. I'll just do a search.
And a short instant later...
Goddammit!
In
Technology and Software
Posted at 08:39 PM | Permanent link
December 18, 2006
Five things you didn't know about me
There's a massive game of tag going around the blogosphere. I've been tagged by Bill and Dave.
So here goes. Five things you didn't know about me:
- I all but gave up Computer Science in favor of law my junior year of college. I even convinced my friend Evan to do the same... except he actually did :)
- I've been to London, Paris, Amsterdam, and Zurich, but only set foot west of the Mississippi in May of this year.
- I scored higher on the language portion of the SAT than the math portion.
- I play piano.
- I've been skydiving... twice.
I tag Ryan, Jeff, Kurt, Vinnie, and Anton.
In
Matters that are otherwise worthwhile, Technology and Software
Posted at 10:30 PM | Permanent link
December 15, 2006
On Variable Naming in Code
Much is made of the pain of typing long variable names (or function names or class names), but code is usually read more often than it's typed. And when I'm reading code (even if it's my own), I'm grateful for names that err on the side of descriptiveness.
This means:
navigationElement instead of navigation or navqueryString instead of query, queryStr, string, or strlibraryLookupUrl instead of libraryLookup or url
The exceptions are common language idioms which any programmer could reasonably be expected to know (ie: cons in Lisp, def in Python, x as an index into array loops). These should be abbreviated as their meaning is more intrinsic and independent of the name.
In
Technology and Software
Posted at 08:37 AM | Permanent link
