Adding primary keys in Rails migrations

Module: ActiveRecord::ConnectionAdapters::SchemaStatements

The API doc on add_column() refers to column_types which say that it can be of type :primary_key. This is not true. add_column cannot use :primary_key as a type. Currently, I have no idea how to indicate that a field is a primary key and needs to be auto incremented.

You might have to drop the entire table and create it again.

Are migrations executed within a transaction?

[Rails] Are migrations executed within a transaction?

As I'm writing migration changes to the database, I find that rollingback is a pain sometimes, because of writing self.down(). When it fails, I have to reset the database. While this really isn't a problem since no real data is in there (and all the fixtures are added automatically), it is an extra step.

I figured migrations would be executed within a transaction, but apparently, it's not. This was the only link I could find about it, and the guy just says you can't. Anyone know why you can't?

Nitpicking "if" structure

So what would be better?

def method
  if !event
    return nil
  end
  return Table.find_first_by_name("oak")
end

def method
  return nil unless event
  return Table.find_first_by_name("oak")
end

def method
  return !event ? nil : Table.find_first_by_name("oak")
end

I figured the first is a bit clearer, but longer...and while the third is shorter, I'm not sure that a coverage tool would flag parts of it as uncovered. And the second...well, having two returns seem kinda ugly. What do you think?

Soft robots and haptics

"Chance favors the prepared mind."
- Louis Pasteur

Even though I feel like my grasp of advanced math is not as solid as it should be, I don't think it's beyond me to understand it, if I spent enough time on it (and maybe asked someone if I got stuck). But I don't feel like this is innate. Anyone should be able to understand advanced concepts if it were explained correctly. Geniuses might get it faster than others, but everyone should have the mental capacity to grasp abstract concepts eventually.

However, when it comes to creativity, innovation...ahh...that's something that's practiced. But even if you do work on it, sometimes you might not have gotten something that someone else thought of. And in that capacity, I feel that Louis Pasteur's quote above signifies to me the reason why.

I had always been looking for some type of gel substance that received and gave some type of signal as an input device, but usually to no avail. It was with this sitting in the back of my mind where, "Luck favors the prepared."

I was talking to a coworker next door, and he was working on robotics and autonomy. He was excited about a prototype for a body that he had constructed. A common problem for robotics is mobility: wheels can't go everywhere. So what he and his cohorts developed was the concept of a soft robot...a robot with a soft, amorphous body. He showed me a disk with membrane on one side, and plastic on the other. Trapped inside the disk was a dark colored liquid. When you feel the liquid from the side of the membrane, it doesn't feel special...just like liquid under a membrane. But when you put a magnet on the plastic side, it hardened the dark colored liquid, which you could now feel on the side of the membrane. Basically, the idea was to have a sac with this dark liquid as a body that you can control through magnets.

I was playing around with it while talking to him. It was pretty neat. When moving the magnet, you can feel a gel-like hardness underneath the membrane. I was thinking to myself, "This is pretty cool. You can use it to create robots that do massages with this." Immediate after--though I did not express it--I knew that the porn industry would have a field day with such a technology.

And then as I usually do, I reverse whatever I was doing, just to be playful. I stuck the magnet on the plastic side, and started pushing the hardness around through the membrane. As a result, the magnet on the other side was moving around also. I looked at my coworker and said, "You know, you can use this as an input device...I'm sure there are magnetic sensors, right? So you can push the hardness in the membrane around, detect it, and send it electronically somewhere else. You guys probably thought of it already, right?" He was kinda surprised and said, "No, we hadn't thought of that at all." I saw a flicker of an idea in his head, but he didn't divulge what it was. He seemed please with himself.

A week or two later, he came up to me and said, "hey short-timer!" And then he told me that his cohorts were really excited about the idea. Basically, for robotic-assisted surgery, it can be an input device that provides haptics (force-feedback). So, in the future, if you see any soft-membrane input devices for robotic-assisted surgery, it was cuz of me playing around with a membrane. Haha, my little claim to fame.

Rake options and tasks in Rails

I feel stupid for even posting this at all, but after typing:
rake -h
rake --help
rake help

Without too much helpful information, it wasn't until reading docs that I found
rake --tasks
goes a long way in seeing what you're able to do with rake. It kinda opens up your world.

Rails 1.0's fixtures are different than from before

Faster Testing with Rails 1.0

Was wondering wth was going on. Good thing for the web. According to Mike Clark, if you're reading the Rails book, "Agile Web Development with Rails", make sure you take note of the errata with Rails 1.0. The instantiation of fixtures as attributes and hashes are not done by default anymore with Rails v1.0.
self.use_transactional_fixtures = true
self.use_instantiated_fixtures = false

The reason being that having to instantiate all those attributes will take too long with a large fixture to test. Now, instanciations are done ON DEMAND with each test. And if they are done, they are cached. Therefore, you can either choose to override and change the use_*_fixtures settings in your test code, or you can change all your code from:
@table["my_fixture"]
to
table[:my_fixture]
table(:my_fixture)

RubyForge: RMagick: Hints and Tips

RubyForge: RMagick: Hints and Tips

So for image manipulation, you need imagemagick, and rMagick, which is the ruby layered on top of it. However, I had trouble installed rMagick because it complained about, first imagemagick not being installed (when it was), and then about missing libraries.

I didn't want two copies of the same app floating around on my system, by installing the tarball, so I found this large (and helpful) explanation.

Usually this problem occurs when installing RMagick over a version of ImageMagick/GraphicsMagick ("xMagick") from a binary package such as an .rpm or .deb. The problem occurs because the package installs just xMagick but omits one (or all) of the libraries that it uses, such as the FreeType library or the XML parsing library. Or the libraries are installed but not the header files that RMagick needs.

So I had to look for the gem, which for me is under
/usr/local/lib/ruby/1.8/gems/1.8/gems/rmagick-1.10.0/

And read the config.log file. I found that I was missing "libMagick.so" and "libBZ2.so" I had both of these installed, but I used YUM's "provides" command to find the packaged I needed that provided those libraries. I found the development packages and installed those.
yum provides libMagick
yum install libMagick-devel
yum provides libbz2
yum install libbz2-devel
gem install rmagick

:: Howtos : Keeping Fedora Up to Date with Yum

:: Howtos : Keeping Fedora Up to Date with Yum

I've used linux for a while now, but the intricacies of how the OS works and is put together is still a bit shrouded. I've developed a lot on a linux machine, but haven't really administered one, til recently.

I've always built my apps from source tarballs, mostly because at least this way, I'll know where I installed it /usr/local/ and it's all in one place. With RPMs, I have no idea where it put the files...but then again, maybe that's the point...that I don't have to. But even then, I've found RPMs are to use...mostly because I could never remember the flags.

Then comes yum on fedora. I like it a lot so far. It's a bit slow, but it finds the repositories, knows which packages need to be updated, and numerous other things. It also finds which packages provide a library that you need for another install, which I used to install rmagick gem. The best part is that the commands are whole words. :)

The Nature of Tagging: Public vs Private

By implication, tags are public. However, should tags be public or private? That's been the ongoing debate between me and Chris. Chris's stance is that tags should be private, because he only cares how he classifies things, and not how everyone else classifies things. My stance is that the power of public tagging is in its search of everyone's content, not from its way of classifying individual content.

Tagging is no more than keywords on things for grouping. And if tags were private, it would be no more than that. Gmail has a new feature that allows the user to group contacts. Public tagging gets its power from the aggregation and feedback loop of lots of people's sets of tags. The statement that one wouldn't care how other people classify things is true to you if you don't use other aspects of tagging, namely, the searching of new information through tags. If you only use tagging for classification, then it makes no difference whether the tags are public or private. The power of tagging is not that it's a better classification system; it's a way of utilizing humans to create a search index.

How could the index comprised of an aggregation of other people's tags be anything other than a hodgepodge of random keywords? That would only be true if the set of tags that people use on a particular object would be independent (uncorrelated) with everyone else's set of tags. Now, we know that to be untrue for bookmarks due to del.icio.us's work. This is because words with content are correlated with each other. Therefore, there is a limited set of keywords that people will use for any single piece of content. In fact, it's because of this that search engines can do their job. So while one person's set of keywords may not be the same as another's set of keywords, on average, they will overlap with each other. Thus, if you're searching for more content on the same subject, that's something public tagging does a really good job of. And that's a task that lots of people do on the internet...they're looking for related content.

Now, will [public] tagging work for classifying or searching all other objects? With the rage about Web 2.0, there are some people that think that everything should be tagged. Not necessarily, I say.

Tagging has been demonstrated to work if an object has intrinsic properties; a book is a book to everyone. But what if you're tagging your relationships to an object? I think that changes the nature of tagging a little bit. Because the relationships to an object is not the same for all people; and more importantly, sometimes these relationships are non-transferrable between people. A book will always be a book to anyone, but a book that your father gave you on your eighteenth birthday will be a relationship between that book and only you, and not between that book and anyone else.

That said, there is sometimes a shared (collective) relationship between groups of people and an object. A group of people might feel that Lover's Overlook is a special teenage place for them, but not everyone in the world would share the same relationship to Lover's Lane. But everyone can agree that Lover's Lane is a make-out place because it's an intrinsic property of the object. Therefore, I will have to curb my hard statement before that tagging relationships between objects would be uncorrelated. It will be less correlated than tags on intrinsic properties of an object, but some degree of correlation would exist. And therefore, you can search for all other objects that have the same relationships to people.

So should tags be public or private? I think that objects with intrinsic properties that people are searching for is very condusive to public tags. However, objects such as 'gifts I received for my birthday' might not be condusive to private tags. You might not care what everyone else received for their birthday. In addition, since they are different people than you, you might not want the same things they got.

I think the application of tags to objects in a system should be carefully scrutinized, rather than just following the assumption that everything is good for tagging. Are there instances of objects that should be privately tagged as opposed to publicly tagged?