After a friend briefly explained the whole Apple TV thing to us, Nikki had an insight into the situation which I had to quickly jot down as she said it:
“That’s not gonna beat piracy.. you can’t beat free. I dont even think that’s gonna change piracy at all, cause the reason people don’t do it is because either people are morally against it or they just dont know how. And charging 99 cents per TV show is not gonna make people know how to do it.”
She’s so smart <3
Mongrel2 seems like a great took for a lot uses.. one of them is perfect for hobbyists like me, who want to run a single server that contains web apps in many different languages (for experimentation, practice, whatever). Soon as I find the time, I plan to run degutis.org on Mongrel2 and start pumping out web apps like a maniac in whatever language I fancy that week. Sound plan, right?
I rarely fall into a situation where I overwork myself to the point where I’m both too exhausted to move and extremely hungry. Tonight I am in that situation. And it really sucks.
Today I spent from 8am this morning until 6pm tonight pretty much cleaning, packing, and moving furniture into a moving truck which is going to leave tomorrow at noon, independently carrying our belongings cross-country, where we will meet them on September 1st.
Right now I am at a point where I feel too tired to lift to my mouth the spoon containing my oatmeal, and too hungry not to. My body is shaking. And there’s still more to pack and carry to the truck.
Honestly I need is to eat, calm down, and lay in bed. I’m only typing this so that I can keep myself occupied mentally through this difficult situation, with which I know no other way of coping.
I’m also going to call the pastor to our local church and ask if they can find someone who is willing to watch our children tomorrow morning so we can have the freedom to continue packing the remaining items and putting them into the truck. But tonight I have no more strength.
And I just found out that my wife feels the exact same way as I do physically (minus the hunger) but that she’s working through it and continuing to work even though she is mentally, physically, and emotionally exhausted. (That was her description to me just now.)
I’m praying that we can make it until tomorrow at noon without overworking ourselves again like this, but while making sure we have all of our belongings in the truck so we don’t have to spend the money buying new dishes or whatnot when we finish moving. (We desperately need every penny we can get right now.)
Specifically, I’m hoping to find one that:
- Is not a fun, exciting, or fast-paced work environment
- Has no video games or weekly office parties or pinball machines
- Does not offer free lunches every day
These frills are not motivations for me to apply. Solving problems during work is satisfying and enjoyable all by itself. I enjoy learning and creating.
Unfortunately, most jobs I run across are advertised as the opposite of this. Am I alone in feeling this way about what an ideal job would be? Am I just old fashioned or weird or something?
This morning I had an urge to implement currying in Ruby, despite the fact that it’s already there, just to see if I could do it, and as a sort of mental exercise to test my understanding of proc objects in Ruby. Since Proc#curry already exists, I wrote a reverse-curry method instead. This is what I came up with:
class Proc
def rcurry(arg)
Proc.new do |*args|
self.call(*args, arg)
end
end
end
def concat(*args)
args.join
end
meth = method(:concat).to_proc
curried = meth.rcurry('1')
puts curried.call('2', '3', '4', '5') # => 23451It works because Proc objects in Ruby 1.9 have the same flexible argument system as methods do.
(Obviously it’s a very simplified version that does not work in the same manner as Proc#curry, but that’s okay because this is just an exercise!)
Something cool just happened. My wife just now asked me if I was growing my hair out, when she noticed I hadn’t shaved it in a week or two. Since I hadn’t thought about that yet and hadn’t decided, I just said “I don’t know”. That’s not the cool part.
Right after she asked me and I thought this about my thinking, I actually thought about how I thought about this, in Ruby. I considered her asking me this to be the same as steven.growing_hair_out? which is a Ruby method call, requiring a direct response. Then I realized that I had recently changed the implementation from this:
def growing_hair_out?
decide_if_growing_hair_out # returns true or false
endto this:
def growing_hair_out?
method(:decide_if_growing_hair_out)
endwhich evaluates the question lazily, instead of right away. (Granted, she still has to ask again later via stevens_response.call to actually get an answer!)
Thinking about thinking in terms of a programming language is bizarre if you ask me! Aren’t human brains just awesome? :D
My favorite thing about Ruby is how open its object model is. You can not only add to classes but you can remove from them as well. This comes in handy if you ever want to write a thorough proxy class that forwards a message onto another object.
For instance, in the code below, we can create an instance of Proxy, and even though it inherits from Object, it won’t respond to any of its inherited methods such as :class, :dup, :respond_to?, :extend, :inspect, etc.
This makes it possible to do fun things like create a Ruby library that lets you poke and prod Ruby objects over TCP/IP and get the results back, all over a network. I haven’t looked into it, but I imagine this is at the foundation of DRb’s implementation. In fact, I’m pretty tempted to port SocketObjC over to Ruby for the fun of it. (The only difference I can see at a glance between that and DRb would be the lack of synchronicity.)
class Proxy
instance_methods.each do |m|
undef_method m unless m == :object_id || m == :__send__
end
def initialize(real_object)
@real = real_object
end
def method_missing(sym, *args)
@real.__send__(sym, *args)
end
end
a = []
fun = Proxy.new(a)
fun << 42
p fun[0] # => 42
p fun.class # => Array
p a # => [42]
class Fun
def initialize(sym)
@str = sym.to_s
end
def method_missing(symbol, *args)
Fun.new("#{self} #{Fun.new(symbol)}")
end
def to_s
@str
end
end
def method_missing(symbol, *args)
Fun.new(symbol.to_s.capitalize)
end
# should output "This is awesome!"
puts this.is.awesome!
Over the weekend I was working on my first Ruby project, an IRC bot. One of the ways it handles IRC events is via a simple event callback registration system which uses Proc objects, pretty standard Ruby stuff. However, I decided to add a new way to handle events by just defining a method in the form “handle_[eventname]” within a plugin object. Thus, to handle join events, you would implement handle_join.
The first argument to these methods is the event info (as a Hash). The second is the raw line itself. Obviously the latter is rarely needed in an event handler, so I wanted these methods to be able to have the option of omitting them. In Objective-C, you can do this just by passing all the arguments, and the runtime will just drop off the rest of the args if you don’t implement them, so there’s never an argument error. In Ruby, it requires a little more work, since passing the wrong number of args to a Proc object can raise an exception (depending on how the Proc was created), but it’s still doable.
Originally I was going to convert the Method object into a Proc using Method#to_proc, and then use Proc#curry, which would have been neat, but much too complex for this little problem. Instead I found a simpler solution. All you have to do is limit the full array of arguments to the number of arguments the method actually takes, using Array#first in conjunction with Method#arity, and splat the result when passing it to Method#call. Here’s the code I ended up using to make it happen. Ruby is pretty amazing.
I’m liking Ruby’s object system a lot. I love the concept of mixins and I love the way ruby instance methods/variables work. A lot of it is great.
But Ruby has one huge difference from Python: Ruby is completely okay with there being N ways to accomplish a given task, with each solution being subtly different.
Take the for..in feature for example. Most people I have asked tell me it’s just syntactic sugar around list.each do..end, but it’s not.
for a in [1,2,3]
puts a
end
a #=> 3
Versus:
[1,2,3].each do |a|
puts a
end
a #=> NameError: undefined local variable or method `a' for main:Object
Personally the “N ways to do something” philosophy looks like a huge recipe for disaster. Fortunately most people I’ve asked about the differences told me to simply use the latter and avoid the former. Good solution, but it only masks the underlying problem, which is Ruby’s error-prone philosophy.
