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.

Advertisements

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.

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