Innovation is force fed; someone get the lube!

In an earlier post, I had talked about what users know and what you know, when it comes to listening to your users. That said, when it comes to building new products, either in another line, or something to replace your old product, you should go back to not listening to your users--at least on the first draft. The act of creation is effectively the effort of one (or the few). At least when it comes to first drafts, too many cooks do spoil the broth. That might be a bit Ayn Randian, but the only thing I've ever heard of where design by committee was successful was the Space Shuttle and the Lunar Lander. (If there's more examples, please enlighten me.)

When you're building a product you're essentially forcing your world view onto others. You're basically saying, "I find this to be a pain. And this is not the world as it should be. As a builder, I can correct it after mouthing off for a while." And this is usually why people don't warm up to innovative ideas readily--someone is shoving their world view in your face. And unless you're someone that has been looking for a solution to the same problem when it's introduced to you, you won't be receptive to it. Even innovative people suffer from this affliction of shortsightedness.

“Don’t worry about people stealing an idea. If it’s original, you will have to ram it down their throats.” – Howard Aiken

Because innovative products can be so jarring, they should soften the blow a bit--or as others like to call it lowering the barriers. This is where influences from design, gaming, and etiquette can help.

Beyond the current trend of sleek lines, horn-rimmed glasses and black turtle necks of designers, design isn't just about putting a gradient background on your web app, or painting things in pastel colors. Hackers making a product should understand that design is the study of how to best solve communication and usability problems with limiting constraints. What information would the user need to know right this second, and how should you convey it to make it as easy to understand as possible? And from the answers to those questions will emerge a form that is also pleasing to the eye.

Gaming is an avenue more familiar to hackers than design is. However, games are often seen as mere trifles of play reserved for kids--though this is changing. If you've played enough video games and thought about WHY they're fun, will help also, because to bring out the essence of fun in what's normally perceived as tedium will give your product an edge. In the lecture about the ESP game by Luis von Ahn, he laments the fact that there's millions of cycles of human computation wasted. There was 9 billion hours played of solitaire last year (est.). Considering that the Empire State Building took 7 million hours and Panama Canal took 10 million hours, that's a lot of wasted hours. We should be able to put those cycles to good use by making people play games to solve problems that computers can't yet solve. So a symbiosis of humans and computers can be considered a large distributed computer to solve hard problems, such as object recognition in images. You might have played it.

In other web apps, the idea of a collection is a powerful mechanism of play. Social networking sites play on the idea of collecting friends, much in the same way that in Pokemon, you "gotta catch them all!". In others, the idea of a scoreboard is a powerful motivator, as seen on Digg and Reddit.

And last of all, the idea of etiquette seems far removed from being applicable to innovative products. However, no matter how much technology people surround themselves with, we are still social beings and will have social tendencies. Because of that, we expect certain behaviors and interactions between ourselves and our machines. We get mad and frustrated at computers and devices because they're usually not very polite. They stop responding when they're busy doing something, but don't tell you what they're doing. They don't remember what you told them last time and asks us over and over again. And when they don't know how to ask for help when something goes wrong, since the error messages are unintelligible to most users. These are all hallmarks of an annoying person, and were it a real person, I'd have kick them to the curb.

The iPod, and in general, Apple products, are known for their politeness. When I first got an iPod, it was the 5th generation. I was surprised that it stopped the music, if the ear buds got unplugged, and that it turned itself off, after it's been paused for a while. Basically, it knew what was going on, and reacted to it in a fashion that makes sense to its owner. That sounds like the promise of Agent based software hyped so long ago. Maybe it should make a slow come-back.

The sad thing is, computer apps and devices have been annoying us for so long, that we have kinda gotten use to it. I think as research on classifiers become more readily available to programmers as being embedded in the language, and the rising influence of designers in applications, we should see a trend towards more polite products. If you can make a product that is polite, it'll go a long way in gathering fans.

In the end, you want people to use what you build if it has value. And users want to GET THINGS DONE, so they can move on with their lives. All products should solve problems, there's no doubt that it's essential. All other points are moot if your product is useless. But given that it does solve a problem, if it is also beautiful, fun, and polite, it will go a long way in lowering barriers so that we can all have pearls Before Breakfast.

Comments on the death of computing

This article is starts off as a complaint or a lament in the area of edge CS, and probably serves as a warning, though the conclusion is probably not as hopeful or optimistic as it could be. Or it could possibly be the lack of imagination. To start:

There was excitement at making the computer do anything at all. Manipulating the code of information technology was the realm of experts: the complexities of hardware, the construction of compliers and the logic of programming were the basis of university degrees.
...
However, the basics of programming have not changed. The elements of computing are the same as fifty years ago, however we dress then up as object-oriented computing or service-oriented architecture. What has changed is the need to know low-level programming or any programming at all. Who needs C when there's Ruby on Rails?

Well, part of it is probably a lament by the author--presumably a scholar--on the loss of status and the general dilution in the quality of people in the field. And the other part is about how there's nowhere interesting left to explore in the field.

To address the first part, it's well known that engineers, programmers (or any other profession) likes to work with great and smart people. Usually, when a leading field explodes you're going to attract these great and smart people to the field. However, the nature of the field of technology is to make doing something cheaper, faster, or easier. And as technology matures, the more the barriers to entry in the field lowers. And as a result, you'll get more people that couldn't make it before in the field and the average quality of people dilutes. People use to do all sorts of research on file access. But now, any joe programmer doesn't think about any of that and just uses the 'open' method to access files on disk. But that's the nature of technology, and it's as it should be.

The environment within which computing operates in the 21 century is dramatically different to that of the 60s, 70s, 80s and even early 90s. Computers are an accepted part of the furniture of life, ubiquitous and commoditised.

And again, this is the expected effect of technology. Unlike other professions, in engineering one is able to make technology which gives people leverage over those that don't use it. This gives the advantage of acceleration and productivity that's scalable that you won't find in other professions. If you're a dentist, there is an upper limit to the number of patients you can see. In order to be even more productive, you'll need to create a clinic--a dentist farm--to parallelize patient treating and you need other dentists to do that. If you're an engineer, the technology that you build is a multiplier, and you don't even need other people to use the multiplier.

But at a certain point, the mass adoption of a technology makes it cheaper, and hence, your leverage over other people isn't that great, and you begin to look for other technologies to make your life easier or give you an edge over your competition. But these are all applications arguments to CS; while important in attracting new talent, it doesn't address where the field has yet left to go on the edge.

As for whether CS is really dead or not, I think there's still quite a bit of work to be done at the edges. Physics in the late 1800's claimed that there wasn't much interesting going on there until General Relativity blew up in their face. Biology has had its big paradigm shift with Darwin, but there's still a host of interesting unknown animals being discovered (like the giant squid) and I'm sure alien biology or revival of Darwin's sexual selection would help open up another shift. Engineering suffered the same thing in the early 1900's, when people with only a background in electromechanical and steam powered devices thought there wasn't much left to invent or explore, until the advent of computing spurred on by the Second World War.

In terms of near-term computing problems, there's still a lot of work to be done in AI, and all its offshoot children, such as data mining, information retrieval, and information extraction. We still can't build software systems reliably, so better programming constructs are being ever-explored. Also, since multi-core processors are starting to emerge, so better concurrent programming constructs are being developed (or rather, taken up again...Seymour Cray was doing vector processors a long while back)

But I'm guessing the author of the article is looking for something like a paradigm shift, something so grand that it'll be prestigious again, and attract some bright minds again.

In the end, he is somewhat hopeful:

The new computing discipline will really be an inter-discipline, connecting with other spheres, working with diverse scientific and artistic departments to create new ideas. Its strength and value will be in its relationships.

There is a need for innovation, for creativity, for divergent thinking which pulls in ideas from many sources and connects them in different ways.

This, I don't disagree with. I think far-term computing can draw from other disciplines as well as being applied to others. With physics, there's currently work on quantum computers. In biology, there's contribution to biology from bioinformatics and the sequencing of genes, as well as drawing from it like ant optimization algorithms and DNA computers. In social sciences, there's contribution to it using concurrent and decentralized simulation of social phenomenon, as well as drawing from it like particle swarm optimization.

One day, maybe it will be feasible to hack your own bacteria, and program them just as you would a computer. And then, a professor might lament that any 14 year old kid can hack his own lifeform when it use to be in the realm of professors. But rest assured, there will always be other horizons in the field to pursue.

Ruby Quiz #122 Solution: Checking Credit Cards using meta-programming

So this is the first time I actually did a RubyQuiz for real. I spent probably 3 or 4 hours on it. Not too shabby. And, I got to do a little bit of meta-programming! It's basic meta-programming, but I liked the solution. Brief intro to the quiz:

Before a credit card is submitted to a financial institution, it generally makes sense to run some simple reality checks on the number. The numbers are a good length and it's common to make minor transcription errors when the card is not scanned directly.

The first check people often do is to validate that the card matches a known pattern from one of the accepted card providers. Some of these patterns are:

      +============+=============+===============+
     | Card Type  | Begins With | Number Length |
     +============+=============+===============+
     | AMEX       | 34 or 37    | 15            |
     +------------+-------------+---------------+
     | Discover   | 6011        | 16            |
     +------------+-------------+---------------+
     | MasterCard | 51-55       | 16            |
     +------------+-------------+---------------+
     | Visa       | 4           | 13 or 16      |
     +------------+-------------+---------------+ 

There's more rules for each credit card at wikipedia. So normally, how would you do this with OO design? First thing that came to mind was creating a general CreditCard base class, and use polymorphism to implement the rule for each type of card, which is a subclass of CreditCard (i.e. Mastercard extends CreditCard). The problem with this, I've always found is that there's a proliferation of classes when you do something like this. People have solved this problem with other patterns, such as Factories, to build families of classes.

But that's a lot of structure that I didn't want to write for a little RubyQuiz. So I opted for case statements at first:

def type(cc_num)
  case cc_num
  when /^6011.*/
    return :discover if cc_num.length == 15
  when /^5[1-5].*/
    return :mastercard if cc_num.length == 16
  ...other card rules...blah blah blah
  end
  return :unknown
end

But as we all learned from having to maintain a proprietary server program written in C nested 11 or 12 layers deep all in one main file, case statements suck and don't scale (guess who had to do that?). So what's a better solution? I'd like to think I came up with a nice one.

With dynamic programming languages, I find that a lot of the problems that design patterns solve simply go away. And with meta-programming, it can be a much more flexible tool to solve design problems, rather than with design patterns. In a way, I created a very very tiny domain specific language for checking credit card type and validity. All you need to do to use it is define the rules in the table above in your class which subclasses credit card checker:

require 'credit_card_checker'

class MyCreditCardChecker < CreditCardChecker
  credit_card(:amex) { |cc| (cc =~ /^34.*/ or cc =~ /^37.*/) and (cc.length == 15) }
  credit_card(:discover) { |cc| (cc =~ /^6011.*/) and (cc.length == 16) }
  credit_card(:mastercard) { |cc| cc =~ /^5[1-5].*/ and (cc.length == 16) }
  credit_card(:visa) { |cc| (cc =~ /^4.*/) and (cc.length == 13 or cc.length == 16) }
end

CCnum = "4408041234567893"
cccheck = MyCreditCardChecker.new
puts cccheck.type(CCnum) # => :visa 
puts cccheck.valid?(CCnum) # => true

Neat! So this way, you can have any type of credit card checker you want, in any combination. And if suddenly there was a proliferation of new credit card companies, you can add them pretty easily. How is this done? Well, let me show you:

require 'enumerator'

class CreditCardChecker
  def self.metaclass; class << self; self; end; end

  class << self
    attr_reader :cards

    def credit_card(card_name, &rules)
      @cards ||= []
      @cards << card_name

      metaclass.instance_eval do 
        define_method("#{card_name}?") do |cc_num|
          return rules.call(cc_num) ? true : false
        end
      end
    end

  end

  def cctype(cc_num)
    self.class.cards.each do |card_name|
      return card_name if self.class.send("#{card_name}?", normalize(cc_num))
    end
    return :unknown
  end
  
  def valid?(cc_num)
    rev_num = []
    normalize(cc_num).split('').reverse.each_slice(2) do |pair|
      rev_num << pair.first.to_i << pair.last.to_i * 2
    end
    rev_num = rev_num.to_s.split('')
    sum = rev_num.inject(0) { |t, digit| t += digit.to_i }
    (sum % 10) == 0 ? true : false
  end
  
  private
  def normalize(cc_num)
    cc_num.gsub(/\s+/, '')
  end
end

If you don't know much about meta-programming yet, you might want to try _why's take on seeing metaclasses clearly along with Idiomatic Dynamic Ruby. Don't worry if it takes a while...I was stumped for a while also.

Anyway, the magic is in the method credit_card. Notice it's between "class << self" and "end", which means that this method is defined in the singleton class of the class CreditCardChecker. But you can just think of it as a class method. Same thing with the method metaclass(), it is a class function that returns the singleton class of the caller.

Now, the thing is, this isn't very exciting in itself. However, notice that credit_card() is executed in the subclass MyCreditChecker. This means that when inside credit_card(), metaclass returns NOT the singleton class of CreditCardChecker, but the singleton class of MyCreditCardChecker! Then when we proceed to do an instance_eval() and a define_method(), we are defining a new method in the singleton class of the subclass MyCreditChecker. Inside the method, it will call the block that evaluates the rule given for that card. If true, it returns true and false if false. The only reason I did it that way, is so in case the block returns an object, it'll return true instead of the object.

Therefore, to any instance of MyCreditChecker, it will look like there's a class method with the name of the credit card. So if you did:

require 'credit_card_checker'

class MyCreditCardChecker < CreditCardChecker
  credit_card(:amex) { |cc| (cc =~ /^34.*/ or cc =~ /^37.*/) and (cc.length == 15) }
end

MyCreditCardChecker.amex?(cc_num) would be a valid method that checks if the credit card number is an American Express Card. And what cctype() method does is that it cycles through all the known credit cards and returns the first one that's valid. The rest is standard fare, so I won't go through it.

And oh, btw, each_slice() and each_cons() got moved to the standard library, so you have to include enumerator in order to use it--even though the official ruby docs say that it's still in the Enumerables class in the language.

Inconsistent virtual realities for social augmentation

Cognitive Daily: If you want to persuade a woman, look straight at her:

"There is a considerable body of research showing that eye contact is a key component of social interaction. Not only are people more aroused when they are looked at directly, but if you consistently look at the person you speak to, you will have much more social influence over that person than you would if you averted your gaze....Since each individual's virtual experience is generated separately, in a "room" full of people, each person could experience the phenomenon of everyone else looking at them. Everyone can be the center of attention, all at the same time!"

That's an interesting way to view things. I hadn't thought too much about that, since generally, simulations and games work hard to maintain game state world consistency.

But as we know from Horchow and Carnegie, people are interested mostly in themselves. Inconsistent realities to facilitate or even manipulate social interactions is both fascinating and a bit unnerving due to its immediate implications of social engineering, as most modern people in the western world in this day and age believe in free will.

However, I think it can certainly put to good use, especially in terms of customer service, to help make a customer feel like they are getting special and speedy attention. In the future, if there are Non-Player Characters who are store clerks in either augmented or virtual realities, a customer can have the benefit of seemingly personalized attention.

I can see this implemented in a physical store, where a customer walks in and an augmented store clerk helps them out. And if two customers, say two girls out shopping together, are listening to the same augmented store clerk, one can change the image to make it seem like the clerk is addressing them both at the same time.

As for the article's claim of gender differences, the sample size is pretty small, given only 6 male pairs and 6 female pairs for each of the 3 study groups. But the difference between genders are pretty significant in the graph...and I don't see any manipulation of the graph to make results seem more significant than they are offhand.

Adobe open sources Flex, it'd be nice for mobile too

Now that's news. I think it's a good strategy on their part, since there's still work to be done in the adoption phase of user interfaces, both on the web and mobile devices. What is most interesting is if Adobe plans to use some version of Flex as a platform for mobile devices. Currently, it's done in JavaME, and after trying it out, it was hard, because the tools were still a bit inadequate, and the fact that it's still not easy to get applications on to phones.

With an open sourced language for rich/heavy front-ends, I wouldn't be surprised if this gains quick adoption, as I see just OpenLaszlo and Microsoft's Silverlight as being the alternative. AJAX will have to come up with other tricks up its sleeve, like faster javascript engines...This whole scene will be something to keep an eye on, as it'll be interesting how it plays out.

Reconnecting to database server in Rails

I've had more posts up my sleeve, though I haven't had time to actually polish them up. I should make my blog posts go back to its roots, where I just said anything as a first draft. That way, you'll get more stuff. So as usual, I happened across my travels through Rails-land and saw something that I don't think gets seen too often...since I couldn't find it on the first page of Google. It was an error like this:

>> user = Account.find(1)
ActiveRecord::StatementInvalid: Mysql::Error: MySQL server has gone away: 
SELECT * FROM accounts WHERE (accounts.id = 1) from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.0/lib/active_record/
connection_adapters/abstract_adapter.rb:128:in `log'
...blah blah blah...

Since connections are expensive (in terms of time) to make, web frameworks, and anyone making raw connections to the database, will use the same connection for multiple SQL queries, and close the connection when you're done.

Usually you won't see this in Rails, because it does a pretty good job of maintaining the connection, either per session, or per user action in the controller. However, when you have a background process running using something like BackgrounDrb, if there is no activity between the background worker and the database for a couple hours, the database is going to close the connection, and the worker will still think the connection is valid. In other words, ActiveRecord::Base.connected? will return true.

Here is also where I found a use for 'else' in blocks as mentioned by Jamis Buck. When the connection goes out cold, we can't really tell that its' because it's been sitting there too long. It will raise an ActiveRecord::StatementInvalid, which is the same thing raised when you have a bug during development. As a simple fix, I just wanted something to try reconnecting to the database once, just in case it was only because the connection was cold.

class SomeBackgroundWorkerClass
def initialize
  @already_retried = false
end

def some_database_operation
  begin
    Account.find(1)
    # or some other database operations here...
  rescue ActiveRecord::StatementInvalid
    ActiveRecord::Base.connection.reconnect!
    unless @already_retried
      @already_retried = true
      retry 
    end
    raise
  else
    @already_retried = false
  end
end
end

So, that way, as long as it succeeds every other time, it'll keep on going. Tip!

Log files in XML, YAML, or JSON?

Currently, log files are almost always in a form that is hard for machines to parse. It's either in a comma separated form, or an arbitrary proprietary format. Why is that? The primary assumption of log files is that a human will read it. But usually, no humans read it unless something goes wrong, and it's always in a reactive sense.

Of course, no human wants to look at log files all day long. This is the kind of thing that machines would be great at...if only they could read it. What we can do to help log file processing is to put it into formats that are easily transferable and readable by both humans and machines. Isn't that the primary goal of data formats such as XML, YAML, and JSON? A machine that can read log files can monitor it and do analysis on it to present information to users that wouldn't be apparently when just reading the log file straight through.

And yet, most of our log files are in proprietary formats, especially for web servers and web applications. This might not be as much of a problem for long-standing programs like Apache. They've been around long enough that their log file has stabilized and there are specialized programs to parse and analyze those log files.

In addition, I think (correct me if I'm wrong), JSON format allows you to carry code as if it were data. Having that code to perform specific transformations on the log data when processing it might be something useful. Therefore, it would be like having transformed data transparently available to the parsing/analysis program. It would also cut down on the amount of extra programming that is needed for the analysis program, since the log would know how to generate specific pieces of information not explicitly written in itself.

Code quickie: How to interlace two arrays in ruby

Hrm, I'm not sure whether it's worth posting or not, but I was looking for a way to interlace two arrays in ruby. This is what I came up with originally, and it worked fine for a bit:

class Array
  def interlace(other_array)
    interlaced_array = []
    self.each_with_index { |x,i| interlaced_array << x << other_array[i]}
    return interlaced_array
  end
end

This code has the problem that on arrays of different sizes, it'll either leave off the longer array's remaining elements or insert nils for the shorter array. This isn't a good default behavior. What we'd like is for the longer array, whichever one it is, to get its remaining elements tacked on the end of the interlaced array after the elements in the shorter array have run out.

I decided to do it recursively. I haven't written anything recursive since that post on Erlang.

class Array
  # interlaces an array with another array.  It dovetails the two arrays together.
  # 
  #   [1,2,3,4,5,6].interlace([7,8,9]) # => [1, 7, 2, 8, 3, 9, 4, 5, 6]
  #   
  #   [1,2,3].interlace([1,2,3,4,5]) # => [1, 1, 2, 2, 3, 3, 4, 5]
  def interlace(other_array)
    return other_array if self.empty? 
    return [self[0]] + other_array.interlace(self[1..-1])
  end
end

Great, now it works on different sized arrays! What you'll notice is that unlike most recursions, this one "switch places" with the other array on every recursion with the call, other_array.interlace(self[1..-1]). It's the first time I've seen a recursion like this. It certainly simplifies the code immensely, since you don't have to check for which array is bigger or smaller. Note, however, that this only works because the method is public. The technique doesn't work for private recursion helpers.

While you don't get to use recursion all that often, I find that its solution is often pretty elegant compared to iteration. I think that it will be useful when we start to use more data structures that are more fractal in nature. Currently, we have lists and trees. Hrm, there might be some possibilities here. For now, we'll keep this short, and if I come up with anything on this front, I'll let ya'll know! Tip!

Updating just the join table

Having a model that has a has_and_belongs_to_many relationships with another model affords you the convenience of a bunch of added on methods that get created when you define the relationship. These are all pretty nice. But I found that I had to forgo these methods for a more crude method.

Let's say you have two models, taken from the Rails book: Article and User.

class Article < ActiveRecord::Base 
  has_and_belongs_to_many :users
end

class User < ActiveRecord::Base 
  has_and_belongs_to_many :articles 
end

In order to create a new article and associate it to a user right away, you can use create!:

user = User.find(session[:user].id)
user.articles.create!(:title => "The Art of FizzBuzz")

But sometimes, an article might be linked to other models as well. Let's say that there's a Shelf model, and an Article habtm Shelves too. Then, you'd have to pull something like:

user = User.find(session[:user].id)
shelf = Shelf.find(params[:shelf_id])
article = user.articles.create!(:title => "Go and foobar yourself")
shelf.articles << article

Now, that last line is tricky. It's adding the new article to the articles of a shelf. Technically, it should just be inserting ids in the join model. However, that's not the case. It will ask shelf to load all its articles first, and then update the join table. Now, if you're going to manipulate articles of that shelf later on in the controller method, I think this would be the way to go.

However, if you're importing articles from the net, that might not work so well. In that case you just needed to add the association in articles to shelves in the join table. The current implementation of <<, concat, and push seems to enforce an explicit query for it at least once.

Therefore, if "shelf" has a lot of articles, then you'll experience a large slowdown in importing your articles--for every new article, you're asking the database to return a list of all current articles on that shelf. Database caches common queries, but in this case, it doesn't help, since you're importing a new article every time, which can belong to different shelves. But the time you come back to the same shelve, it may have been cleared from the cache already.

This is very much like Joel's story about Shlemiel the Painter. It's not that <<, concat, push is implemented poorly, but that it's used for a different scenario with different assumptions--that you're going to be doing other things to the collection within the scope of the controller method.

The only solution I've come up with is an ugly one. I created a model out of the join table, and added a method called link. It finds the associated link, and if it doesn't find one, it creates it.

class ArticlesShelves < ActiveRecord::Base
  def self.link(article, shelf)
    find_by_article_id_and_shelf_id(article.id, self.id) || 
      create!(:article_id => article.id, :shelf_id => shelf.id)
  end 
end

This has lowered the importing of articles from a minute and a half for each article belonging to a shelf with lots of articles, to about 0.5 second for each article on a low powered machine. I personally don't like this solution, since it introduces a very specialized model object with only one purpose, rather than a cohesive set of responsibilities.

While it is possible to push the method "link" to both Article and Shelf, I'm not sure exactly how to query for just the join table if the active record counterpart ArticlesShelves does not exist, other than using find_by_sql(). But even then, how do you execute an "insert" SQL query?

If you've got a better solution, let's hear it. :)

Erlang and neural networks, part II

Two weeks ago, I did a post about Erlang (Part I), and how a simple feed-forward neural network might be a nice little project to do on the side, just to learn about Erlang. Here's what came next.

State of the Purely Functional

In the transition from imperative/procedural programming to functional programming, there are obviously things that you have to get over. You'll hear this from a lot of people just learning functional programming for the first time (myself included). The hardest thing for me to get over in a pure functional language is the absence of state. My first reaction was, "Well, how do you get anything done?"

Not having state has its advantages, and you'll hear stuff about side-effects and referential transparency. But I'd like to think of it as, things that don't have state can't be broken--they just exist. However, state is useful in computation, and different languages have different ways of getting around it. With Haskell, you use monads. At first, I figured it was the same with Erlang. But in this short tutorial on Erlang, it simply states that Erlang uses the threads to keep state.

This maps pretty well with what I'm trying to do. Each perceptron will be a thread, and send messages back and forth to each other as they fire and stimulate each other.

The essence of a perceptron

So once again, this is a perceptron. It's a weighted sum (a dot product) of the inputs, which is then thresholded by f(e). So we'll write a thresholding function and a weighted sum in Erlang.

We start by declaring the name of the module, and the functions to export from the module.

-module(ann).
-export([perceptron/3, sigmoid/1, dot_prod/2, feed_forward/2, 
replace_input/2, convert_to_list/1]).

I exported most of the functions, so I can run them from the command line. I'll remove them later on.

First we write our thresholding function. We will use the sigmoid function as our thresholding function. It's pretty easy to explain. A value, X goes in, another value comes out. It's a math function.

sigmoid(X) ->
  1 / (1 + math:exp(-X)).

Since I wasn't as familiar with all the libraries in Erlang, and I wrote a dot product function, and it wasn't too bad. Erlang, for the most part, doesn't use loops, just as Ruby doesn't. They both can, if you want to write a FOR control function, but the common way is to use library functions for list processing, list comprehensions, or recursion. The first part is the base case, and the second part is what you'd do if the "recursion fairy" took care of the rest.

dot_prod([], []) ->
  0;
dot_prod([X_head | X_tail], [Y_head | Y_tail]) ->
  X_head * Y_head + dot_prod(X_tail, Y_tail).

Simple, so far, right? So to calculate the feed forward output of a perceptron, we'll do this:

feed_forward(Weights, Inputs) ->
  sigmoid(dot_prod(Weights, Inputs)).

The body of a nerve

So far, so good. But we still need to create the actual perceptron! This is where the threads and state-keeping comes up.

perceptron(Weights, Inputs, Output_PIDs) ->
  receive
    {stimulate, Input} ->
      % add Input to Inputs to get New_Inputs...
      % calculate output of perceptron...
      perceptron(Weight, New_inputs, Output_PIDs)
  end.

This is a thread, and it receives messages from other threads. Currently, it only accepts one message, stimulate(Input) from other threads. This is a message that other perceptrons will use to send its output to this perceptron's inputs. Notice that at the end of the message, we call the thread again, with New_Inputs. That's how we will maintain and change state.

Note this won't result in a stack overflow, because Erlang somehow figures out not to keep the call stack. I'm guessing it knows it can do so, since no state is ever kept between messages calls that everything you need to know is passed into the function perceptron, so we can throw away the previous instances of the call to perceptron.

We do come to a snag though. How do we know which other perceptron the incoming input is from? We need to know this because we need to be able to weight it correctly. My solution is that Input is actually a tuple, consisting of {Process_ID_of_sender, Input_value}. And then I keep a list of these tuples, like a hash of PID to input values, and convert them to a list of input values when I need to calculate the output. Therefore, we end up with:

perceptron(Weights, Inputs, Output_PIDs) ->
  receive
    {stimulate, Input} ->
      % add Input to Inputs to get New_Inputs...
      New_inputs = replace_input(Inputs, Input),

      % calculate output of perceptron...
      Output = feed_forward(Weights, convert_to_list(New_inputs)),

      perceptron(Weights, New_inputs, Output_PIDs)
  end.

replace_input(Inputs, Input) ->
  {Input_PID, _} = Input,
  lists:keyreplace(Input_PID, 1, Inputs, Input).

convert_to_list(Inputs) ->
  lists:map(fun(Tup) ->
              {_, Val} = Tup,
              Val
            end,
            Inputs).

The map function you see in convert_to_list() is the same as the map function in ruby that would go:

def convert_to_list(inputs)
  inputs.map { |tup| tup.last }
end

Now, there's one last thing that needs to be done. Once we calculate an output, we need to fire that off to other perceptrons that accept this perceptron's output as its input. And if it's not connected to another perceptron, then it should just output its value. So then we end up with:

perceptron(Weights, Inputs, Output_PIDs) ->
  receive
    {stimulate, Input} ->
      New_inputs = replace_input(Inputs, Input),
      Output = feed_forward(Weights, convert_to_list(New_inputs)),
      if Output_PIDs =/= [] ->
           lists:foreach(fun(Output_PID) ->
                           Output_PID ! {stimulate, {self(), Output}}
                         end,
                         Output_PIDs);
         Output_PIDs =:= [] ->
           io:format("~n~w outputs: ~w", [self(), Output])
      end,
      perceptron(Weights, New_inputs, Output_PIDs)
  end.

We know which perceptrons to output to, because we keep a list of perceptron PIDs that registered with us. So if the list of Output_PIDs is not empty, then for each PID, send them a message with a tuple that contains this perceptron's PID as well as the calculated Output value. Let's try it out:

Test Drive

1> c(ann).
{ok,ann}
2> Pid = spawn(ann, perceptron, [[0.5, 0.2], [{1,0.6}, {2,0.9}], []]).
<0.39.0>
3> Pid ! {stimulate, {1,0.3}}.

<0.39.0> outputs: 0.581759
{stimulate,{1,0.300000}}
4>

So you can see, we got an output of 0.581759. We can verify this by doing this on our TI-85 calculator:

x = 0.5 * 0.3 + 0.2 * 0.9
Done
1 / (1 + e^-x)
.581759376842

And so we know our perceptron is working feeding forward! Next time, we'll have to figure out how to propagate its error back to adjust the weights, and how to connect them up to each other.

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

Google Maps of the World of Hello World

Google maps now allows the ability to create your own maps. The title link is a map of the major programming languages in use in the world. So it's like lots of little hellos around the world. Cute. Looks like Africa, India, Australia, and South America have a lot of catch up to do. They don't do all the languages in the world, but Japan would also have quite a few if it listed all the variants in the Lisp family.

It's also noticeable that the coasts dominate with programming languages. UIUC's gotta step up.

But most significantly, making your own maps has been a long time coming, and I would have originally thought they'd leave mappr.comFrappr alone in this field. But I think it makes strategic sense for them, especially if they make it easy to post maps that people create.

"Web 3.0" and "Killer App" sound like "Crystal Ball" to me

Ahh, web 3.0.

Indeed, as nanobeeper's asks and puts into perspective, What's up with the web 2.0 angst?, there doesn't seem to be a need to get bent all out of shape over the term. And yet, I usually don't use the term myself and am pretty reluctant to, for fear of being someone-who-doesn't-know-what-they're-talking-about, like the braying butthole in Jeffery Zeldman's famous post. It's what happens when marketers get out of control, and generally, it applies when someone that knows just enough to be dangerous. Fanboys of Japan is a good example. If you meet someone that LOVES Japan, they've either only watched anime (or been to Japan once or twice), or they've lived there for at least a decade. Usually the former.

But what I want to post here today isn't want I think is or isn't web 3.0, but more about the usage of the term. Why do people use it?

Killer app 3.0

It's an interesting parallel that ever since Visicalc came out and the term "killer app" was termed, people since then has been talking about the "killer app" on this platform or that. "The killer app of the web is..." "The killer app of the mobile phones is..." It's certainly reminds me of the way people talked about web 2.0. "Web 2.0 is...." "Web 3.0 is..."

The similarity between talking about web 3.0 and talking about killer apps is that when people talk about them, they're using those terms to try to communicate what they see, predict, or would like to be the future. Technologists are, if anything, always looking for the Next Big Thing. We're use to change, and in fact, we thrive on it. We're all interested in the future of change because if we're right about it, that kind of information is an advantage over whatever our goals are. But as we all know, predicting the future is well, inaccurate at best.

I'd trade intelligence for hindsight

Often times, we have limited scope, experience, and knowledge. That certainly will affect what we think to be in the realm of the possible and what will be in the realm of the impossible. If you look back on quotes about technology predictions, some of them might stun you at how stupid they are. But then again, you have the gift of hindsight. Keep in mind what technology was available at the time for them to relate to the new tech, as well as the fact that first iterations of any product sucks--as Guy Kawasaki so famously points out. (If you want to read more, they're from wikipedia)

"Heavier-than-air flying machines are impossible." -- Lord Kelvin, British mathematician and physicist, president of the British Royal Society, 1895

"Who the hell wants to hear actors talk? The music — that's the big plus about this." Warner Bros. was investing in sound technology though Henry Warner was more excited about the potential of scoring over dialogue. [3]

"Caterpillar landships are idiotic and useless. Those officers and men are wasting their time and are not pulling their proper weight in the war." -- Fourth Lord of the British Admiralty, 1915

"The wireless music box has no imaginable commercial value. Who would pay for a message sent to no one in particular?" -- Associates of David Sarnoff responding to the latter's call for investment in the radio in 1921.

"While theoretically and technically television may be feasible, commercially and financially it is an impossibility, a development of which we need waste little time dreaming." -- Lee DeForest, American radio pioneer and inventor of the vacuum tube, 1926

The last two quotes are notable. Lee DeForest, who had enough foresight and innovation to see that a radio had value, couldn't see beyond that to see how a television would have value just five years later. We all have limited breadth and imagination, but some people are worse than others. It would do you well to ignore those people. Sometimes you can recognize them if they counter with "Why would I ever do [insert whatever idea you just told them]"

And even if we had perfect scope, perfect breadth, it would still be hard. Predicting the future is computationally intensive.

As for myself, I didn't immediately see the value of social networks apps until Facebook showed up, even though I read research papers on social networks. And currently, I don't really get Twitter and Scribd, but the fact that people are using it, well, there's value somewhere in there.

So what's the chorus in all the noise?

So where does that leave us with Web 3.0? If you look at it as people merely trying to say what their predictions about the future of the web, it doesn't conjure up as much anger, because you know they may very well be wrong. But collectively, what everyone predicts to be web 3.0 will have some value because part of it might be a self-fulfilling prophecy. If we all say it's true, you can be sure that some of us will work to make it true.

Based on that flash in the pan, I was curious. What was the collective consensus on what web 3.0 is? I looked in two places. Wikipedia and del.icio.us. Just from eyeballing it, it seems to be that people are in consensus, at least about the semantic web. This would be the type of thing that Inkling Markets would be good for. I created a market for it, if you're so inclined to buy stock on web 3.0.

So take what any individual says to be the future with open mind and a grain of salt, but really pay attention to where the global trend is moving. As Joe Kraus says, you want to see what the trend is, take it out of geek land, and ride that wave.

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.