“Variables in Erlang are *mutable* so assigning a new value to an existing variable is not allowed”

Should read:

“Variables in Erlang are *immutable* so assigning a new value to an existing variable is not allowed”

Next paragraph: “first match assigns a value to the variable.” -> “first statement assigns a value to the variable.”

A bit further on: “Fibonacci is always a nice way to show things in a functional language.” -> “Fibonacci numbers are an easy demonstration the capabilities of a functional language.”

And I would put in the URL to the Wikipedia articles on Fibonacci numbers, http://en.wikipedia.org/wiki/Fibonacci_number. Most of your readers will know the sequence but some may not or may not remember it clearly.

Sorry, had to stop here to write reviews and some blog posts. Will be mentioning your post as a resource on Erlang on my blog.

newFS = new LogicalSchema.LogicalFieldSchema(((LogicalRelationalOperator)op).getAlias()+”::”+fs.alias ,fs.schema, fs.type, fs.uid);

Wonder if I had spotted that if I had checked before writing the post.

You can hit the same error without a join:

Let’s say you have a relation called “foo” with fields “some_field” and “some_other_field”.

You want to extract all the values of some_field, so you write:

newfoo = foreach foo generate foo.some_field;

You are iterating over foo, so at every iteration, you are working on a single row from foo, which has a schema (“some_field”, “some_other_field”). Note that in this schema, there is no foo in sight. So referencing foo.some_field means you are trying to read foo while iterating over foo.. this causes the universe to collapse onto itself and the dreaded “not a scalar” error pops up.

The short answer is no. Search consists of data collection, creation of an index and ranking. Traditional data collection is done by crawlers following links. Obviously that’s not optimal for real-time search unless you treat oft-changing sites differ…

I did not add the user page to revoke access at the same time, but the basic support for that was included. Adding it meant another haml view and some basic sinatra post handling. This addition was probably a couple of days work.

Sticky sessions in the load balancer will avoid problems related to request tokens not being synchronized between database replicas in time.