Crazy small nuances

I'm not particularly fond of nuances. Ruby is suppose to be easy to use and intuitive to the user. But as it grows, it has some crazy little nuances.

For example, there's a difference between system and exec. I wouldn't have known, as I was skimming the docs for something I needed. Were it not for this post by jayfields, I would have had no idea.

And there's something in Ruby 1.9 called "funcall", in which it's definitely not at all intuitive how that's different from "send". I hope these are just growing pains, because while Ruby is nice when you're taking it out for dinner on the first couple of dates, I hope it doesn't get abusive the more time that you spend with it.

Users know the problem. You know the solution

What's considered by now to be mantra out there in 'user-centric web development land', is "listen to your users". But in all that hubbub, you'll also hear, "don't listen to your users all that much."

So what's up with the paradox? Well, like all puzzles, it's only a puzzle if you think it's all or nothing. It seems pretty obvious once you think about it, but it bears reiterating:

Listen to your users when it comes to what's wrong with your stuff. Users are more familiar with problems with your application than you are. They are pained by how much your application sucks, and how it doesn't help them get on with their lives. So they'll complain to you, in hopes that you're listening and you'll fix it.

But users often times have no idea what solutions are good. They'll often offer up solutions to their problems with your application when they're telling you what's wrong with it. Often times, they won't even tell you the problem, they'll just offer solutions.

"You should put tagging in here."

"Why not put a chat room so we users can talk to each other?"

However, they usually don't have the overall vision, sufficient scope, and adequate background for improving the product. That's your job. You have to get beyond what users are saying to figure out exactly what the problem is, and find a solution that fits the overall vision of the product, and perhaps solves other problems all at once also.

A default behavior for failure or nil

I read "The Rails Way", mainly because Jamis Buck writes there. Three days ago, they had actually posted one thing that I had address just a few days prior--that is, how to prevent users from looking at other users' data.

I have to admit, I was rather tickled by my solution. It's nice when you figure things out. But alas, after reading Koz's post on association proxies, I have to admit, I like his solution better. At least I made it to anti-pattern #3.

So what did he do? He simply used the find in the association, and let things throw an exception otherwise.

def show
 @todo_list = current_user.todo_lists.find(params[:id])
rescue ActiveRecord::RecordNotFound => e
 flash[:warning] = "Stop playing around with your urls"
 redirect_to '/'
end

It also takes care of the case where you have say, many items that belong to a todo_list. You can load it by using :condition in the association find. The only reason I can think of not to use it is if it happens to be a slow solution. But no use optimizing if you have no measurements and hard numbers.

Koz's solution let the default behavior of the method take care of things. This is a way of thinking that I need to start using more of.

I was use to nil being a failure state, something that you checked, and if it happened, everything's gotta stop--like the examples I often saw in C:

status = CallSomeMethod(with, some, parameters);
if status == NULL {
  return ERROR_CODE
  // or throw some exception here if you're using C++ or Java
}

Often times, these things got cumbersome, because NULL (or even an empty array or hash) was not considered to be a valid input for many functions, and would stop computation by returning error codes and throwing exceptions in C++.

One of the things that I found nice about the code from Ruby gurus was that it was conventional to do (and subsequently, I saw in Perl):

setting = params[:setting] || "default"

Instead of:

setting = params[:setting].nil? ? "default" : params[:setting]

Or

setting ||= "default"

Instead of:

setting = setting.nil? ? "default" : setting

It was because the operator || took nil by default, and had an appropriate behavior for dealing with nil, and that has made all the difference in being able to chain functions together. In addition, having default failure behaviors require you not have to write error checking code all over the place either.

I'm not sure what this is called (if anyone knows, enlighten me), but a completeness and liberal in what you accept for your input and strict in what you output also applies here to methods and functions. I think it makes code more readable, because it is not peppered with common sense error checking code.

Capistrano and Mongrel are easy to use, but deployment is still hard

This summary is not available. Please click here to view the post.

Does link_to_remote() submit using a GET or a POST?

A little while back, I had a post about how to have two submit buttons with form_remote_tag. A question was raised about having a POST as opposed to a GET request. It seemed like a short enough question, but after looking into it for about 15 minutes, I figured it was worth it to type something up.

To recap, when I first was doing web stuff in high school, I never got what the difference between POST and GET were. It seemed like the author of my HTML book then didn't really get it either. However, it wasn't until DHH started raving about REST as a web service did I get it. in short, when a user submits a form, GET puts the form contents in the url, and POST puts the form contents in the body of the HTTP request. The implication (apparently related to REST) is that you'd only use GET for server requests that didn't change content on the server--the request had no side-effects. That way, the same URL would refer to the same resource, time after time. Alternatively, POST is for server requests that change the content of the server. And that's why we care.

I find that reading documentation helps. So I first looked at the browser source for a link_to_remote() call and it's pretty clear it uses Form.serialize() to convert the form, and then sends it along using Ajax.Request(). The question is, does it send via POST or GET?

According to the documentation for link_to_remote(), it sends via POST by default.

The method used is by default POST. You can also specify GET or you can simulate PUT or DELETE over POST. All specified with options[:method]

Example:

  link_to_remote "Destroy", :url => person_url(:id => person), :method => :delete

I also checked it out with a quick check inside a controller with a breakpoint to see if a link_to_remote() call really sends a post. I put a breakpoint inside a controller method called by link_to_remote:

$ ./script/breakpointer 
Executing break point at ./script/../config/../app/controllers/friend_controller.rb:60 in `test_ajax'
irb(#):002:0> request.get?
=> false
irb(#):003:0> request.post?
=> true

As for a regular form_for() call, simply use the :method option. I think by default it also uses POST.

Erlang and neural networks, part I

So it's been a whole week since my interesting post about the OwnershipFilter. I was investigating several things all at once, all the while wrestling with internal motivation (another post, at another time). In any case, I thought I'd blog about it entirely when I had something full and concrete to show you. However, if it takes me that long, I might as well blog about it as I go along--and it might be more fun for you anyway.

Trace it back

It started with an article about how the free lunch is over for software engineers that a friend sent to me about two years ago. It basically stated that developers have been riding on the wave of Moore's law to save their butts, and it's not going to last forever. In addition, it's been known for a while that chip manufacturers are moving towards multi-core processors to increase performance. If developers are going to take advantage of hardware like they have been, they're going to have to learn how to program concurrent programs.

The problem is, programmers suck at it. It's well known that concurrent programming, as it stands, is not easy for humans. Even Tim Sweeney, the guy that architected the Unreal Engine (no mere programming mortal), thought it was hard. It was when I started looking beyond threads as a concurrency abstraction that I tripped over a programming language developed specifically for concurrency.

Yet Another Programming Language

A friend of mine, who is a teacher (i.e. not a programmer), recently asked me, "Why learn more than one programming language?" Ahh, little did she know that programming languages inspire what verges on religious debates between programmers. My short answer was, "Each tool is better at one task than another." I was looking for another language that might do concurrency better.

I had always thought that I should learn more about functional programming. It seemed like an odd beast to me, especially since you don't change state through side-effects. "How do you get anything done?" It's kinda like when you first learned that you don't need GOTO, and subsequently, when you learned that FOR loops suck.

And yet, I never really found a need or a small project I could do with functional programming that might prove to be satisfying. It was only due to the search for better concurrency abstractions that I ran across Erlang, a functional programming language that is used explicitly because it's good at concurrency. In fact, it's pretty much the only one out there that touts concurrency as its strength.

It uses the actor model, where processes share no data and just pass messages around. Because there's nothing shared, there's no issue of synchronization or deadlocks. While not as sexy-sounding as futures or software transactional memory, the actor model falls nicely along the lines of complex and emergent systems--systems that have locally interacting parts with a global emergent behavior. Hrm...could one of these systems be good for a small side project to do in Erlang?

How Gestalt, Mr. Brain

Artificial neural networks seemed to be the perfect thing actually. A quick, quick diversion into what they are.



A feed-forward artificial neural network is basically a network of perceptrons that can be trained to classify (ie. recognize) patterns. You give the network a pattern as an input, it can tell you the classification of that input as an output.

You can think of a perceptron much like a neuron in your brain, where it has lots of inputs and one output. It's connected to other perceptrons through these inputs and outputs and there are weights attached to the input connections. If there is a certain type pattern of input, and it passes a threshold, the perceptron 'fires' (i.e. outputs a value). This in turn might activate other perceptrons.

Even simpler, a perceptron is modeled as a function that takes a vector x as an input and outputs a number y. All it does is take the dot product of the input vector x with weights vector w, and pass it through a non-linear and continuous thresholding function, usually a sigmoid function. And you connect them up in layers, and you get an artificial neural network, that can learn to recognizeclassify patterns if you train it with examples.

It has to learn patterns by adjusting the weights between perceptrons in the network after each training example, and you tell it how wrong it was in recognizing the pattern. It does this by an algorithm called back propagation. It's the same page I lifted all these pictures from. I put all their pictures in an animated gif to illustrate (click on it to watch):



In the first part, the example propagates forward to an output. Then it propagates back the error. Lastly, it propagates forward the adjusted weights from the calculated error.

I think the shoe fits, sir

Why would this be a good fit as a subject to play with Erlang? Well, if you'll notice, each perceptron only takes input from its neighboring perceptrons, and only outputs to its neighbors. This is very much in line with the actor model of concurrency. Each process would be a perceptron, and would act as an autonomous agent that only interacts with other processes it comes into contact with--in this case, only other perceptrons it's connected to.

In addition, you'll also notice that in the animation, the perceptron values are calculated neuron by neuron. In a concurrent system, there's no reason to do this! You can actually do the calculation layer by layer, since the calculations of any individual perceptron only comes from the outputs of the perceptrons in the layers before it. Therefore, all outputs for perceptrons in a layer can be calculated in parallel.

Notice, however, that layers need to be calculated serially. I had originally thought that with the learning process propagating back and forth, maybe it could be pipelined. On closer examination, however, the best one can do is to feed-forward the next input one layer behind the adjusting of weights, to make the learning process go faster.

So I'm going to give it a shot on the side, and document it along the way, since a quick search on google revealed that though people talked about it, no one's ever really given some snippets on it. Wish me luck!

Erlang and Neural Networks Part I
Erlang and Neural Networks Part II
Erlang and Neural Networks Part III

Stream Copy YouTube, Revver, Etc.

For lots of times in the past, I was always annoyed that I couldn't save content offline, and always had to view it online--especially when there's no guarantee that the content will stay there. So, I was a little bemused, but not altogether surprised, that you can save streaming copies of videos using Ruby. The source code is fairly short...maybe 20 lines or so. And while I haven't tried it out, I've actually been able to read it through, and it's nice to be able to read the works for people far better than me, even if it's just table scraps.

Well, if you want to try it out, the balloon is here. A balloon is a web page that has ruby embedded in it, so that you can run it in ruby. Just make sure you have ruby installed on your system, and follow the instructions on the balloon.

Keep users from looking at other people's data with a simple ownership filter

Happy St. Patrick's day everyone!

Well. Everyone's pretty familiar with authentication. That's where you force the users to login, before you'll show any of the pages. Usually, this is achieved with a before_filter, so that you're not checking if a user has logged in in the beginning of each action in the controller. This keeps your code mighty DRY. But what about ownership of data? Within any web app, you have data that's owned by some users, and other data that's owned by other users. Just because they're logged in doesn't mean that they should be able to see other users' data.

Oh, these tables of mine

A good example are friends in a social network app. Each user has a set of Friend records in the database that belongs to them. (btw, don't use the User table below in your own app. you never want to store cleartext passwords in the database. Check out authentication tutorials)

create_table :users, :type => "InnoDB" do |t|
 t.column :username, :string
 t.column :password, :string
end

create_table :friends, :type => "InnoDB" do |t|
 t.column :user_id, :string
 t.column :name, :string
 t.column :email_address, :string
end

create_table :posts, :type => "InnoDB" do |t|
 t.column :user_id, :string
 t.column :timestamp, :datetime
 t.column :body, :text
end

Your first instinct sucks

You only want those records of friends that belong to them to be available to them. So what's the first thing that you're inclined to do? Assume that you have the User record as an indication of being logged in the session data.

class FriendController < friends =" Friend.find(:all," conditions =""> ["user_id = ?", session[:user].id])
 end

 def show
   @friend = Friend.find(params[:id])
   unless @friend.user_id == session[:user].id
     flash[:error] = "That friend does not exist"
     redirect_to :action => :list
   end
 end
end

In list, you want to make sure that the list of friends returned belongs to the user, and that's why you find all by the user_id. In show, a user can easily change the URL's id number to reflect another record. You want to check whether that friend actually belongs to them.

While this is all good and well, the problem is, you'd have to do this for every method that you write. We are a lazy kind, so there HAS to be a better way.

Scope it, my brotha from anotha motha

Of course, the Rails geniuses have come up with with_scope() for all ActionControllers.

class FriendController < find =""> { :conditions => ["user_id = ?", session[:user].id] }) do
     @friends = Friend.find(:all)
   end
 end

 def show
   Friend.with_scope(:find => { :conditions => ["user_id = ?", session[:user].id] }) do
     @friend = Friend.find(params[:id])
   end
   if @friend.nil?
     flash[:error] = "That friend does not exist"
     redirect_to :action => :list
   end
 end
end

"But hold on, there's still duplication!" This is only part of the solution. with_scope() is useful if you have multiple database finds within the same block. That way you don't need to keep putting it in the conditions. So how do you get rid of the duplications? With filters, of course.

Add a sprinkle of filter magic

I personally liken filters to programming 'common sense' into the classes. It's what's intuitively understood to have to be done before and after every action. Luckily, there's a filter called around_filter that we can use.

class FriendController < find =""> { :conditions => ["user_id = ?", session[:user].id] }) do
     yield
   end
 end

 def list
   @friends = Friend.find(:all)
 end

 def show
   @friend = Friend.find(params[:id])
   if @friend.nil?
     flash[:error] = "That friend does not exist"
     redirect_to :action => :list
   end
 end
end

So it should be pretty obvious what happened. The around_filter allows you to do one responsibility, both before and after every action in the controller. When the method yields, it gives control to one of the actions below. So you're essentially wrapping every action in the with_scope() defined in the filter.

Yay, that's pretty cool. The code's been DRY'd. We're done, right? But you know as well as I, that because there's more text after this sentence, we can actually take it a step further.

I pull out the method inside, served it and fried

Of course, you have more than one ActiveRecord model that's owned by the user, and in this case, there's another one called Post. So instead of repeating ownership_filter method in every ActiveRecord Object, let's pull it out of FriendController into a class of its own, so that other controllers can use it, using some easy meta programming. Note that you now have a require up top and around filter changed.

require 'ownership_filter'

class FriendController < friends =" Friend.find(:all)" friend =" Friend.find(params[:id])" action =""> :list
   end
 end
end

And this is where we extracted the method to...a file named "ownership_filter.rb" You can put this in your app/controller directory.

class OwnershipFilter
 def filter(controller)
   model_class_name = controller.controller_name.capitalize.to_sym # => :Friend
   model_class = Object.const_get(model_class_name) # => Friend class
   model_class.with_scope(:find => { :conditions => ["account_id = ?", controller.session[:user].id] }) do
     yield
   end
 end
end

It actually took me a while to find out how to do this. I knew you could call methods dynamically with send(), but how do you dynamically get a class? Good thing for posts on ruby-talk. So basically, you take the controller's name and you turn it into a symbol :Friend that is used to find the class, using const_get(), that the constant :Friend refers to, namely, the Friend class.

After that, it's the same as before, you call with_scope() with it. So now, you can use this with any of the controllers that you have in the same ways as you did with the friend controller. I haven't tried it yet with the finds pushed down to the ActiveRecords, but I think it should work the same way. Tip!

Update: I saw that the method I described above is actually an anti-pattern according to Jamis Buck. I've posted subsequently on this topic.

Noiz2sa by Kenta Cho (2002) |

"Noiz2sa is an early study in the art of bullet barrages and playing strategies. It is Cho’s Well Tempered Clavier, in which he challenges several of the aesthetic assumptions of the genre, showing off a talent for composing dizzyingly varied game stages out of a self-imposed set of constraints. "

Here's a diversion for you. I found Noiz2sa by accident in Ubuntu's repositories. It's an abstract 2D space shooter. The review quoted had the funniest--and pretty much the only review for it. The game really is like an exploration of the genre. It's like he said to himself, "what if we had, lots of bullets, and it was hard for you to get shot?" You have no powerups, and you have to make it through 10 substages. It's actually a fun and addictive game, not to mention pretty.

Beyond being a diversion, I thought it was noteworthy that he expresses the bullet patterns in BulletML, a markup language for bullet patterns in 2D shooters. This makes it interesting, since you can attach it to a genetic algorithm, and evolve it as the player got better at dodging your previous bullet patterns through the game. It would not be far fetched to write a server that served these BulletML files in front of of the genetic algorithm, so players can download it, and then report how they did.

BulletML actually just describes a particle system. It might be applicable in certain data visualizations--though I don't know what. What other uses do you think BulletML would have?

Vertical markets for social networking sites

Goodreads is a social networking site for book lovers. That really puzzled and surprised me. I know for a fact that vertical (niche) markets are always better to start off with when you're starting out. It lets you build a community of like-minded people, and it makes you focus your product, which makes it not only easier to build, but makes you design a tighter product.

But the question to me at first impression was, why would people join a vertical market for something that already exists?

Goodreads is a well designed site. It has a core, limited feature, and it's clean, and it's easy to add books that you've read and write reviews on them. One can also see what your friends are reading and what they'd recommend.

However, the big three social networking sites, Friendster, MySpace, and Facebook all have a section where one can list and name books that interest you. And Amazon, already has both places to read/write reviews for each book, and a recommendation system that works pretty well. In addition, you can actually buy books there.

So what does Goodreads have to offer? Well, for one, at this early stage, it's fast and responsive, and the mechanisms for actually adding a book is very easy. In addition, it plays on one of the elements of gaming, which is namely, collecting. And that goes along very well with those that read books...they like to have a full bookshelf (almost like trophies on display). There are many games that focus on the collection aspect. Yugi Oh! and Pokemon are the two that spring to mind. Goodreads is like pokemon...for people that like to read.

In addition, I think the book covers help enforce that idea of a collection, so you can see books in your bookshelf. And not only that, you can segment them according to what you've read, are currently reading, didn't finish, etc. That's something you can't do with a normal bookshelf.

I won't say that it's inevitable that a niche market in an already saturated global market of social networks is going to succeed. But the way Goodreads did it makes sense. In fact, the same mechanism of collection that I outlined above can readily be applied to a social network of fashion geeks.

I own this shirt, or that blouse. I can see what my friends are wearing the next day. I can ask to trade clothes. I can make outfits for myself from my closet, and recommend them to others that have the same pieces of clothing. I can rate clothes and brands, and I can see what the overall trend for different types of clothing are.

I'd be tempted to make it myself, since I usually have an awful time shopping for clothes--I can never remember what I already have. However, 1) I'm not much of a clothes person myself, so I'll only probably work on the 'help me choose my clothes' part, and 2) there are already plenty of niche market fashion sites out there.

What other vertical markets for social networks do you see that would have potential?

Using SMTP over SSL in Ruby

Ruby 1.8 doesn't yet support SSL for both POP3 and SMTP, though Ruby 1.9 does. I had a post earlier on POP3 over SSL, and I didn't think I needed/wanted to do SMTP. Well. here I am. I was googling for some type of solution, and the first site the came up, was well, a non-free solution.

So I did eventually find this solution posted on the rails wiki, which had the original solution from a blogger in japan. It's odd that it's ranked so low on google. Hopefully, one more link to it will help it bump that useless first site off the top link.

---

Wilhem has built Annologger, a tool that lets people worship your dentist appointments.

Sending data from rails to javascript using JSON

RJS templates are a beauty, really. They allow you to run javascript code generated by rails, to be executed on the browser. Usually, this javascript code affects the DOM. But RJS, as it is often used now, is for affecting the look and behavior of a page with javascript. What if you have data that needs to be transferred from Ruby on Rails to the Javascript in the browser?

Well, my first inkling was to write a helper function that converted a matrix in Ruby, one by one, to a matrix in Javascript. But it felt ugly, like specialized complexity that's just in your face. There has to be a better way, since I can't be the first one to run into this problem.

Of course, there is and that's using JSON--JavaScript Object Notation. A simple way to think of it is as XML, with less overhead, because JSON is simply that, a way to represent data in a standard format that's easy for both humans to read and machines to parse.

In Rails 1.1+ (apparently, this has been around since at least May 2006), there's been an extension added to Object class, and that's to_json(). That's right. You can serialize any object in rails to JSON, simply by calling to_json(). However, it's not documented in the Rails API, so your best bet is to google for it.

As a quick and dirty way to demonstrate it, you can have this in your controller:

def some_action
  # some type of data from somewhere in the database
  @data = Data.find(1)
end

and then the following in your view somewhere:

<script type="text/javascript">
  var data = <%= @data.to_json %>
  // act on data as if it were a Javascript object
</script>

You should be able to create helper functions that generate the javascript tags and the enclosing javascript so that it'd be a bit prettier, so it'd look like this in your view instead:

  <%= act_on_data(@data) %>

Neat. So in this way, you can pass your data from your server to code in your views that isn't to be displayed in HTML, but in some other form. One person has tied Adobe's Flex in with Rails for this very purpose. Tip!

But one other thing that I realized after reading through JSON for the masses, is somewhat startling...at least to me. And in hindsight, perhaps it was because it never seemed easy to do in XML.

Usually data transfer languages such as XML and the like are declarative languages. They say the "what" instead of the "how". That hasn't stopped people from trying to do remote procedure calls with XML-RPC. But with JSON, it really is an object notation, meaning that you can put functions as data. So the example I gave before of javascript classes, they can instead be written in JSON notion in the source code and it would still work.

Therefore, the javascript interpreter itself IS the parser for JSON. You don't need a separate parser in javascript like you do in XML. If JSON really does have cross-language compatibility, that's actually rather neat. This implies that JSON-RPC is possible, and of course, a quick search on Google reveals that this is exactly what people are trying.

This kind of reminds me of how Von Neumann's computer architecture was novel at the time because it treated program commands and data as the same thing. Before, computers had one place for data, and one place for a program. You didn't store programs the same place that you stored data. By the same token, it also reminds me of how Lisp's data is pretty much its code, and vice versa, and that's where it derives a lot of its power.

Looking into the future (meaning, here on out, I'm talking out of my ass), perhaps that makes it easier to do distributed computing, and the stitching together of applications so very much desired by the Service Orientated Architecture crowd, but also a host of security issues. You might be able to get javascript programs that update each other on the fly in the field, instead of going all the way back to the server for updates (maybe).

Dynamic fixtures for time didn't seem to be working...

For it while, it seemed like eRb wasn't working in Rail's dynamic fixtures. It use to work, and since I wasn't paying attention, at some point, something like this stopped working:

post:
  id: 1
  timestamp: <%= Time.now.to_s %>

After only a bit of head scratching and thinking (it pays to think!), I figured out that it only takes xmlschema datetime formats. I don't remember it being the case, but yeah, that's what you have to do now...at least for Rails 1.2.0+. So now, it should look like this.

post:
  id: 1
  timestamp: <%= Time.now.xmlschema %>

Hope that saved you some time. Tip!

Traffic reporting for Google Maps

Google Maps just added traffic reporting. Screen shot below:

That's pretty neat, though yahoo has had traffic reporting on their beta maps for some time now. I just like google's interface better...it's fast. And I noticed they also have metro stops now. Neat.

Overriding Time.now for Rails testing

When testing in Rails or otherwise, there are times when you need to test time-sensitive, or time-related methods. Before today, I had a hard time finding a good solution to that.

Let's say that you are a person that loves your friends, and the more time that passes, the more you adore them. You'd want to test the love you give a friend grows over time. So you might have something like this:

class Friend
  def love
    Time.now - @when_first_met
  end
end

def test_love_grows_over_time
friend = friends(:jon_lee)
love_now = friend.love

# do something here to shift time forward
# so that Time.now gives a time in the future

love_later = friend.love
assert love_later > love_now
end

A tip here from Rails Studio inserts a wrapper class around Time, and then proceeds to use their wrapper class MyTime in the rest of their application. This is certainly easier to write, but not always possible. There could be methods that uses Time.now in it that you don't want to rewrite (read: don't want to mess with) in a library that you need to use in the tests of your application. And would you really want to replace all instances of Time.now in every library that you use? Search and Replace!

In Ruby, all classes are open, and you can dynamically add methods to both objects and classes. This means that the importance of the wrappers is rather diminished--unless you don't like the idea of a class being open. Because of this example and others, I'm more convinced that design patterns are signs of weaknesses in a language.

So! I know that in Ruby, you should be able to somehow dynamically override Time.now, in order to run friend.love again. You could override Time.now completely, but accordingly, that messes up times in the Unit testing, so tests look like they end before they begin.

In my searches on google, I happen to come across this thread on Ruby talk, which in turn, had a post to Jim Weiriches's OSCON 2005 slide:

def test_warmer
  Warmer.use_class(:Heater, MockHeater) do
    # Here, anytime a method in Warmer references Heater
    # it will get a MockHeater class instead.
  end
  # Here Warmer is back to normal.
end

Wow, this is pretty neat. What use_class does, is allow you to create a scope where the Heater class is replaced by MockHeater! All classes still use Heater, but Heater is actually replaced with MockHeater within this scope. When the code execute goes back outside of the block, Heater is returned to the original Heater, and not the MockHeater. He achieves this by using a class proxy. You can see the code here.

This is pretty much what I need, so that I'd be able to replace Time with a MockTime. However, as it was written, it doesn't work with Time.now, since now() is a class method. With the way it was implemented, the ClassProxy does not know anything about an object's class methods.

I originally was messing around for hours on how to dynamically add class methods, but I'll spare you the details. What ended up being way easier was just to use method_missing() and pass on any method ClassProxy doesn't know what to do with to the proxied class. So you end up with an extra private method.

class ClassProxy
attr_accessor :proxied_class

def initialize(default_class)
  @proxied_class = default_class
end

def new(*args, &block)
  @proxied_class.new(*args, &block)
end

private
  def method_missing(method_sym, *args)
    @proxied_class.send(method_sym, *args)
  end
end

So now, you should be able to do this in your test:

class MockTime
  def self.now
    Time.now.in 2.days
  end
end

def test_love_grows_over_time
  friend = friends(:jon_lee)
  love_now = friend.love

  Friend.use_class(:Time, MockTime) do 
    love_later = friend.love
    assert love_later > love_now
  end
end

And it should pass! Tip!

A simple isometric engine

For a day or two, I've been messing around with Canvas for firefox. I've managed to code up a very simple isometric engine in about 2 days, provided the canvas tutorial. The hardest part was really just making sure it rendered correctly from back to front. But other than that, everything seemed pretty straightforward.

One thing I'll have to say though, is that this was my first foray into javascript, and it's been more flexible than I had remembered back in 1996. Most people don't take advantage of javascript's language features, since most scripts are fairly short. However, javascript supports object orientated programming, but using a prototype based object instantiation. This means that there is no such thing as classes, but all subsequent objects are created by cloning existing objects. The new objects are then extended to fit the need of the programmer. The following mirrors how you would create a 'class'.

function IsoEngine(canvas_id) {
this.canvas = document.getElementById(canvas_id);
if (this.canvas == null) { return; };
this.ctx = this.canvas.getContext('2d');
var objects = new Array();

this.add_to_scene = function(object) {
objects.push(object);
};

this.clear = function() {
this.ctx.clearRect(0,0, this.canvas.width, this.canvas.height);
}

this.draw = function() {
for (var i = 0; i < objects.length; i++) {
objects[i].draw();
}
};

As you can see, it's all using functions, and it makes for weird looking syntax for those of us coming from a class-based OOP. What was also a pleasant surprise was that javascript supported higher order programming. This means that functions can take other functions as arguments, and if I'm not mistaken, this makes closures possible. It's hell of a lot better than passing function pointers around in C. The syntax for that always left me confused.

Articles and Snippets added to 3cglabs.com

I've revamped the 3cglabs.com webpage a little. I've added a section for articles, linking to what I think are some of my better writings on this blog, as well as a code snippet section that shows off some of what I've been playing with.

Ruby's broken breakpoint workaround

I was messing around with different installations of ruby, and I was aghast when breakpoint stopped working. Having a debugger for imperative programing is one of the fundamental tools in a programmer's tool box. Well, one option is to use the ruby-debug gem, which I have yet to try out.

But I did find that it was because Binding.of_caller() was rewritten (or something) for 1.8.5. In any case, something changed. So if you want a breakpoint and it was broken somehow, try this:

Breakpoint.breakpoint(nil, binding)