Lori's Blog

Between all the stars of all the galaxies in the universe, the odds of there being other life besides us is amazingly huge. So high in fact, that the odds are likely greater then your having been born.

Not a technical source, but I liked the quote:

All of my ancestors (and yours) survived long enough to procreate against considerable odds – in a long, long line going back to a single [celled] organism. And, of course, each of my ancestors (and yours) which produced millions of sperm or hundreds or thousands of eggs were the focal point of a genetic jackpot in themselves. -- Jonathan Schofield

The problem to keep in mind with SETI is that the time-frame for advanced life on a planet is amazingly small compared to the life of planets, star systems, galaxies, and the universe. Even worse is that the further away we look, the older the source for any indication of life will be. And of course, this won't do much at all in the way of helping us find any of the life yet to be in the universe, let alone the galaxy. At best, the most we can hope for is a chance to watch an alien worlds version of 'I love Lucy'.

A signal reaching us from elsewhere in the galaxy could have been in travel for tens of thousands of years, which unfortunately puts a bit of a damper on having any hope to communicate. If we are really lucky, we might even find signals within hundreds of light-years... but even that still removes any chance for us to communicate within our life times.

The hope is that maybe somewhere out there is (or was) life in the right place, at the right time, doing the right thing, haveing sent out a signal long enough ago for it to even reach us. Finding alien life could be one of the most important discoveries in human history. You would be amazed by how much you could learn about a society by watching old broadcasts. It would change our culture, our science, our ways of thinking, and would give a much greater importance to space and space travel.

Over the weekend my girlfriend Julia and I moved into a new apartment. If anyone was wondering why we have not been online, that is why :).

The new apt isn't very far from the old one and its quite nice. We plan on having a house warming party at some point in the near future if anyone is interested!

The new unibody MacBook Pro's are pretty nice from an engineering perspective. They are solid and built well, but are also a PITA to work in and have some weird quirks.

The one thing I really hate about these new macs is the tension on the display hinge clutch. The lid just wants to close on its own when left to its own weight.

It looks like the clutch for the hinge is in the display assembly. While I have no problem working inside the main body of the MacBook Pro, I can't say I am comfortable digging into the display assembly without advice.

Anyone manage to tighten the clutch for the hinge on these things?

ActiveORM is a framework for providing an ORM agnostic API for rails to interact with models. In addition to agnosticism, a goal of ActiveORM is simplifying how rails interacts with ORM's.

inflection =
    case
    when options[:action].to_s == "new"
      args.pop
      :singular
    when ActiveORM.supports? record && ActiveORM.for(record).new_record?
      args.pop
      :plural
    else
      :singular
    end

You will be able to drop in Sequel, Datamapper, or whatever your ORM of choice, and everything should 'just work'. Its coming!

Firefox 3.1 has support for pinch magnification... while this sounds like a wonderful feature, I have found myself constantly zooming by accident.

To disable pinch magnification:

Go to the URL bar and type in about:config, then search for browser.gesture.pinch.in and browser.gesture.pinch.out and set them to blank.

Off you go, pinch zooming free!

My girlfriend Julia and I decided to visit her parents up on Whidbey Island in Washington for Winter Solstice. They are building a new house that is almost finished, so we ended up staying with them in their rental.

We also had lunch at a restaurant they like in Coupeville, the nearest town to their house. I had a Gardenburger and Julia had the seafood platter.

After lunch we ended up driving over the Deception Bay Bridge and admired the beautiful view. Next, we stopped by and looked at their new house, which they are moving into next Monday. Tonight, we cooked minestrone soup for dinner and I worked on the picture formatting for my blog software.

The pictures below are a combination of pictures we took on the drive up to her parents' house, along with the pictures we took from today while visiting the Deception Bay Bridge.

Literally, here is a repost from the Rails blog

It’s christmas, baby, and do we have a present for you. We’re ending the bickering between Merb and Rails with a this bombshell: Merb is being merged into Rails 3!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

What this will mean in practice is that the Merb team is putting their efforts into bringing all of the key Merb ideas into Rails 3. Yehuda Katz will outright join the Rails core team, Matt Aimonetti will work on a new evangelism team, and Carl Lerche and Daniel Neighman (hassox) will be co-starring the effort to bring all this over. We’ve immortalized the merge with plaque page at rubyonrails.org/merb.

What’s being brought over? Some of the key ideas that they’ll be taking with them from Merb into Rails 3 are:

• Rails core: Yes, Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty. Rails 3 will make it easy to run just a bare minimum and then allow you to opt in just the stuff you want, if that’s necessary for your particular situation. Think “rails myapp—core” (and “rails myapp—flat”).

• Performance optimizations: Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over. We’ll also bend the architecture in the places where that’s necessary for a big yield. In short, Rails 3 will get all the performance attention that the Merb guys are known for.

• Framework agnosticism: Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives.

• Rigorous API: Too many plugins break when Rails is updated because it’s not clear where they can safely hook into the internals and when they’re monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades.

This is not a big bang rewrite It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.

I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3. The Merb guys will also be working hard on giving existing Merb users a manageable upgrade path to Rails 3. We’re working with lots of ideas including allowing existing Merb controllers to be mounted alongside new Rails 3 ones. We’ll see how it all plays out, but play out it will.

Also, the Merb guys aren’t just abandoning the existing Merb user base and their applications. They’ll still be doing bug fixes, security fixes, and work on easing the upgrade path to Rails 3. This will all progress in a nice, orderly fashion.

The timeline Rails 2.3 is just around the corner. We hope to wrap up and release in January. It’s a blockbuster release packed with goodies to the tilt. But as soon as that’s done, all eyes will be on Rails 3.

The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 in Las Vegas. Who knows if we’ll make it, but we’ll certainly have made tons of progress on it by then.

So all of these changes are pretty much effective immediately. We’ve already started the collaboration and we’ll be rolling out a bunch of public initiatives announcing the concrete elements of the work under the Rails 3 milestone very shortly.

No hard feelings, just kumbaja This is quite a dramatic turn of events. We went from testy relations to coming together in not very long at all. But I’ve been incredibly positively surprised at how well everyone on both sides have been gelling behind the scenes. The more we talk, the more we realize that we want the same things. And in the few cases were we do care about something different, it’s usually complimentary.

I really hope that everyone within both communities will deal with this news as gracefully as the key contributors from both camps. Let’s just wipe the slate clean on anything that has gone before and cherish that we can now move forward in unity instead of as fractions of the same ideas.

Rails 3 is going to kick ass.

Going to Seattle for Winter Solstice this year. My girlfriend and I will be visiting her Mom.

I hear its freezing as hell there right now... good thing I miss the snow!

Should I use the ruby installation that comes with your mac? Or maybe I should be using MacPorts so I have some isolation and control of my development environment? How do I keep my environment similar to whats being used in production? Do I have to reinstall MacOS if I screw things up?

Its a common problem for Web developers using a mac. You have this wonderful operating system with many of the tools you need... but you still have to figure out how to get everything installed and working before you can get any work done.

Even worse is when you have to test your software on multiple environments. The app runs in Rails 2.0, but what about 2.1? For some reason installing Rails 2.1 while an app is configured for 2.0 causes it to randomly pick bits from both versions to use.

Seamless integration of virtual machine and host for easier development.

My solution to this problem is to use a virtual machine for my development environment. This has some cool advantages like letting you switch between different environments. Its a little harder to get going initially, but once its configured its great!

Pick your virtualization

I personally prefer VMWare Fusion 2 as I've had many issues with Parallels in the past with slow networking and file operations.

• VMware Fusion 2 - commercial
• Parallels 4 - commercial
• Q/QEmu - opensource
• VirtualBox - mostly opensource

Install a guest OS

I personally prefer ubuntu for this. I am currently using the ubuntu 8.10 server install dvd for my virtual machines.

Configure NFS sharing

(Server) On your mac

Create or edit the file /etc/exports:

/Users -maproot=root -alldirs -network 192.168.227.0 -mask 255.255.255.0

This will share your /Users directory only to the network 192.168.227.0, which is private between your machine and virtual machines if you are using vmware. If you are using a different virtualization software, you will need to figure out which subnet to be sharing to.

(Client) On your guest OS

Make sure you have any packages you need for nfs client usage. For ubuntu you will need to do:

sudo apt-get install portmap nfs-common

Create the directory /u

sudo mkdir /u

Add to the bottom of your /etc/fstab

# Mount the /Users share to /u on the guest
192.168.227.1:/Users /u nfs defaults 0 0

Now you will need to modify your guest OS uid and gid to match your macs.

If you run id on both the mac and your guest os, you can see which uid and gid your users are using.

On my Mac, my user's id is 501, and it belongs to the staff(20) group. On my linux guest, my id is 1000, it belongs to a group named after the user(1000), and also belongs to the admin(114) group.

I've modified my guest os as follows: old /etc/group

dialout:x:20:lori
admin:x:114:lori
lori:x:1000:

new /etc/group

dialout:x:1000:lori
admin:x:20:lori
lori:x:114:lori

old /etc/passwd

lori:x:1000:1000:Lori Holden,,,:/home/lori:/bin/bash

new /etc/passwd

lori:x:501:20:Lori Holden,,,:/home/lori:/bin/bash

Change ownership of your home directory.

sudo chown 501:20 $HOME

Finally, mount your /u directory.

sudo mount /u

Start coding!

You can now browse to /u/YourUser and do anything you would normally do during development. Edit files locally on your mac, and run your mongrel processes on the virtual machine.

(optional) Change your home directory

You can change your guest os home directory to be the same as your mac fairly easily.

Edit /etc/passwd and change the bit that says /home/username to point to your directory in /u/MacUser

old /etc/passwd

lori:x:501:20:Lori Holden,,,:/home/lori:/bin/bash

new /etc/passwd

lori:x:501:20:Lori Holden,,,:/u/Lori:/bin/bash

For years, I have hated the way my smile looked. I am really not sure what inspired me to finally get my butt into the dentists office to get my teeth aligned, but I finally did.

Instead of metal braces though, I decided on getting aligners. They are not supposed to be as good alignment wise... but they look a LOT easier to deal with.

Of course... after seeing the alignment projections my dentist emailed me, I couldn't be happier at this point.

Models of my teeth as they are currently:

Models of projected post alignment:

If my teeth end up looking like this when I am done... I don't think there is much to argue with.