nick has a blog!

I tried upgrading my version of rubygems to the most current version by running
sudo gem update --system
Which introduced this error:
/usr/bin/gem:23: uninitialized constant Gem::GemRunner(NameError)
whenever I tried to run rubygems. On the rails forum, I found a fix for it!
Simply add the line to the file /usr/bin/gem (may be different on a mac)
require 'rubygems/gem_runner'
after
require 'rubygems'
This fixed the issue in both Ubuntu and OS 10.4.

I’ve been writing this web app that has the following models: Order, Recipient, Message. An order has many recipients and a recipient has many messages. The recipients are also dependent upon the order and the messages are dependent upon the recipient.

In Ruby code this looks like:
Order.rb

class Order < ActiveRecord::Base
has_many :recipients, :dependent => :destroy
has_many :messages, :through => :recipients
end

Recipient.rb

class Recipient < ActiveRecord::Base
belongs_to :order
has_many :messages, :dependent => :destroy
end

The idea here is that when I delete an order, I also delete any associated recipients and any associated messages. My controller looked like this:

def delete
Order.delete(params[:id])
end


There are a couple things wrong with this. The first and most important thing is that when I delete a row in the order table, it leaves orphaned rows in the order and messages table. I want to delete these rows as well! The next thing is that this isn’t RESTful design. Instead of calling my method “delete,” let’s call it “destroy.” To fix the issue though, we need to use another method that has subtle difference than delete. Instead of delete, I should be using the destroy method. Why is that?

The delete method essentially deletes a row (or an array of rows) from the database. Destroy on the other hand allows for a few more options. First, it will check any callbacks such as before_delete, or any dependencies that we specify in our model. Next, it will keep the object that just got deleted in memory; this allows us to leave a message saying something like “Order #{order.id} has been deleted.” Lastly, and most importantly, it will also delete any child objects associated with that object!

Now my code in my controller looks like this.

def destroy
Order.destroy(params[:id])
end

Whenever I delete an order object, it will delete all child recipient and message rows in the database . This prevents any orphaned rows and allows for consistency in the database!

I couldn’t wait and installed the latest RC of Gutsy Gibbon today. To my surprise the wireless did not work whatsoever! ifconfig didn’t list my interface, but it showed up when I ran lspci. I decided to boot into an older kernel (2.6.20) and it showed up! It must’ve been some sort of module that wasn’t loading in the 2.6.22 kernel. After doing some research I found out that this particular version of the kernel wasn’t loading restricted modules. If you’re having problems using devices that used to work in in Feisty Fawn try running this command:
sudo apt-get install linux-restricted-modules
After running this command my wireless drivers work (ipw2200bg) on my Dell Inspiron 9300.
I’m still trying to figure out how to get my screen resolution back to normal (It’s at 1680×1050 when it should be at 1920×1200). The moral of the story is to wait for everyone else to find the bugs before you make an upgrade!
Edit:
I fixed my display issue. Here’s a snippet of my xorg.conf file. Don’t simply copy and paste it, but use it as a reference to get yours to work
Section "Monitor"
Identifier "monitor1"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 30.0 - 110.0
VertRefresh 50.0 - 150.0
Option "DPMS"
EndSection

Section "Screen"
Identifier "screen1"
Device "device1"
Monitor "monitor1"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1200" "1440x900"
EndSubSection
EndSection
Afterwards I used System->Preferences->Screen Resolution to change the resolution and it works beautifully.
I recommend you make a backup of your xorg.conf file. Who knows when you might mess with it and everything goes wrong. It’s nice to have that backup in case things take a turn for the worse.

The reason I left MySpace was mostly because of all the spam I would receive. “Hot girls” were always trying to add me as a friend to promote their porn site. Luckily I know that girls like that arn’t into guys like me, so I wasn’t tricked like so many other people were. The same thing is happening with facebook. Friends want to send me drinks, say something on my superwall, turn me into a zombie. What the fuck? This is just as bad as the spam I was getting on myspace! One time I actually caved in and added one of the Facebook apps just to see what one of my old co-workers wrote on my “Superwall.” When I added it, it wanted to send an invite to each one of my friends by default. This to me is worm-like activity….as in computer virus-like activity.
There needs to be an option like “Mark Application as Spam” so people can get rid of these troublesome applications.

In the first part of this article I introduced Public Key Encryption and SSH. In this part, we will look at how to use SSH to secure your traffic when using an untrusted network.
As previously mentioned, this was partly inspired by events from SuperHappyDevHouse. At the last event we wanted to promote the idea of encrypting your traffic. One of the ideas was to simply write out the command for encrypting your SSH traffic on whiteboards that were placed around the house for collaboration. This was a step in the right direction as people came up to the group of people I was with and asked for help. At least we brought awareness to this problem.
The code we posted was simple:
sudo ssh -l <username> -NfD <port> <ip>
This creates an SSH tunnel that acts as a SOCKS5 proxy server using the specified port. All traffic going through this proxy will be tunneled through SSH and thus be encrypted. Before we get ahead of ourselves, let’s take a look at the options we specified.

• -l - Specifies the username on the remote server
• -N - Tells SSH not to run any remote commands.
• -f - Has SSH run in the background.
• -D - This is the option that actually creates the SOCKS server.

Thank you Mike Lundy for preparing the command for everyone!
Now that we have SSH running in the background as a SOCKS proxy server, we need to configure our applications to use it. For our example we will look at configuring Firefox to send all of its traffic over SSH.
Under Tools->Options, navigate to “Advacned” and click on the “Network” tab. When you click on the “Settings” button, it will bring up options for “Connection Settings.” Here you can manually configure your proxy settings by clicking the “Manual proxy configuration” radio button and then under “SOCKS Host:” type “localhost” and the port specified in the ssh command you issued earlier under “Port.” Click “OK” and you now have all of your Firefox traffic being tunneled through SSH.

While using either an open wireless network at a coffee shop, an untrusted network, or virtually any open network, your data is exposed. Data passed around on a network is normally unencrypted which means anyone can read it. Imagine the type of data you send over the network: passwords, private messages, more passwords! Have you ever used FTP to update your site? Everytime you do your password is sent in plain text. What about checking your POP email? Again, your password is sent in plain text!
While at SuperHappyDevHouse we have many people on the same unencrypted wireless network. At SHDH13 someone was passively sniffing the network; This person posted a list of collected email address/passwords on the SHDH wiki. The post was quickly taken down and the people were immediately notified; This was a wake up call for for people using unencrypted networks. How can we prevent this from happening again? The solution to this problem is obvious: encrypt! The question is how can we easily do this?

First let’s get some background on something called public key encryption (PKE). PKE consists of two parts: the public key and the private key. The public key can be used by anyone; The function of this key is to encrypt data that is meant for your eyes only. The private key on the other hand should be protected as it decrypts any messages encrypted by your public key. So let’s say Person A, Alice, wants to send a message to person B, Bob. Alice doesn’t want a third party, Eve, to read the message so she wants it encrypted. For simplicity’s sake, let’s pretend Alice and Bob already have established trust and have each others public key (otherwise we are still open to man-in-middle attacks). Alice will encrypt her message with Bob’s public key and then send it. When Bob receives it he will decrypt it with his private key; his response will be encrypted with Alice’s public key and Alice will decrypt it with her private key. That’s the jist of PKE; we could go more in depth and look at digital signatures, but that would be beyond the scope of this article.

So now that we have some background on PKE, let’s talk about SSH. SSH or Secure SHell is meant to replace insecure protocols such as Telnet, FTP, and RCP (SSH, SFTP, and SCP respectively). SSH uses PKE to encrypt its data that is sent over the network. A problem we can see is that SSH seems to be limited in it’s scope. What about POP3 email or regular HTTP traffic? How do we encrypt that? With SSH we can setup a proxy server that will allow us to to send our data through an encrypted “tunnel.” In the next part of this series, we will look at setting up these tunnels and configuring our applications to use them.

I’ve spent the past two weeks in Europe doing a lot of firsts: first time flying, first time out of the country, and first time traveling alone. During my adventures in the various airports I’ve learned a lot of new things about traveling that you don’t read about, so I thought I’d share.

1. Make sure the name on your ticket is the same on your passport. - Nick != Nicholas. I got hassled only once about this when going into the international section at SFO. I had to go wait in another line to get my name changed and then go back to the original line. Bleh! Just do it right the first time.
2. Try to get exit seating. - Exit seating tends to have a lot more leg room that regular seating. On my 10 hour flight from SFO to Munich, Germany, I was cramped and just uncomfortable in the small seating; especially since I have long legs. On my way back from Frankfurt, Germany to SFO, I lucked out and got exit seating, which made that long international flight slightly more tolerable. The person I sat next to said he was able to specify exit seating, so I’m going to look into making sure I get it next time I fly a long distance.
3. For those of you who also need a vacation from your cell phone… - Don’t forget to bring a watch! My cell phone is my watch, so I never wear one. Not bringing one was a mistake because I rely on it to keep myself on schedule. Let’s just say I frequently had to go out of my way to find a clock or ask for the time.
4. Yes you will experience turbulence, no you are not going to die. - This is kind of silly, but I really didn’t know what to expect since it was my first time flying. Sleeping on a plane is hard enough; sleeping on a plane when your heart is pounding is impossible! I really did think at one point that turbulence meant something was wrong with the plane and we were all going to die! Luckily logic and reason came into play and I realized that no one else was panicking, so it all must be normal. After that experience it was mostly smooth sailing.
5. Don’t be a dick. - I missed one of my return flights home (literally by minutes) because my itineray said one airline when it was really another. At the REAL line, I had to use a kiosk that didn’t work at all, so I had to wait in another line. Regardless I was MAD, but I was able to keep my cool. They end up putting me in a Doubletree hotel and even kicked down some extra food vouchers. To contrast this, the woman who was yelling and demanding her hotel voucher only got enough attention to make her shutup.

Those are just a few things that I didn’t know before that I now know. I’m sure most people already know this stuff from experience, but I thought I’d pass down the knowledge anyways. Sometimes it’s the small things that’ll kill you.

It seems that a lot of emerging web apps today are invite-only during alpha/beta. This is smart because it allows you to limit the number of users as you deal with design, coding bugs and scalability issues. However, I’ve noticed that these sites bring a lot of attention to themselves because only a select few are able to gain access to the site. Think about it, you’re get free marketing from these select few who are offering invite codes to their friends. These friends want to know what’s going on, sign up and then brag to their friends about what exclusive service they got into (I would know, I’ve done it :-P)

Like an exclusive Hollywood night club, those who are “on the list” feel like they are part of the “in-crowd” while those who arn’t on the list want in. Sites like pownce and dopplr have benefited greatly from this because they now stand out from hundreds of 2.0 startups that many people could care less about at the moment. Since you need to be invited to joined, all of a sudden people want to see what it’s all about.

Remember when Gmail first came out? The fact that it gave users 1GB of storage was pretty remarkable at the time. However, the craze for Gmail started because it was invite only. I remember people were SELLING invites on eBay for a pretty decent amount of cash. Is an online email provider worth bidding on eBay for? Apparently it was because it was an exclusive service.

I just got done with the book “Getting Real” by 37Signals. This book is a bible for anyone looking to start a web app using minimal resources without sacrificing quality.  “Getting Real” is divided into 16 chapters and covers planning your application up to launching and supporting your application. Each chapter consists of sections that talk about a certain aspect of the chapter. For example, the chapter on supporting your application has a section on setting up forums, a section on why the developers should be on the support frontline, and how to prioritize bug fixes. Each section is backed up by essays and quotes from various people who have been through the web app process . I strongly recommend anyone who is thinking about or is in the middle of developing a web app to check out this book. If anything, it lets you know where they’re coming from when they developed applications such as Basecamp.  Let’s check out some of the important concepts that we’re presented with.

1. Don’t worry about the details; just make a decision. Don’t waste time arguing about the small details of your web app. The type font type used, border size, all don’t matter when it comes to the core of your application. Learn to make a quick decision and move on. Your users will give you feedback to let you know whether or not you’re on the right trail or not.

2. Include only the most necessary features in “1.0” Don’t add any unnecessary features; in fact a lot of the features that you think are necessary may really not be. Cut these features out and include them in a future release. An example they gave was a billing system when they deployed Basecamp. The feature wasn’t necessary until 1 month after their initial release because that’s when their users got billed. Instead they released Basecamp and then worked on it. This was plenty of time to create the feature and everything worked out.

3. Iterate as you go. The nice thing about web apps is that you can instantly deploy bug fixes and new features to your users. This allows you to be competitive since you are able to easily adapt to change and rapidly make fixes. You’re also able to receive instant feedback from your users as you make fixes and/or deploy bug fixes.

4. Create your interface first. Start off with some sketches on a piece of paper and then maybe convert it into HTML/CSS. The reason to do this is because the interface is easier to modify as opposed to re-writing code. As you create your mock-ups questions will be brought up and decisions will be made. It’s better to make those decisions at this stage rather than after you’re into hardcore coding.

5. Learn to market your site from day one. Include a teaser on your front page, screenshots of previews, blog about the development process and features that will be included in the initial release, use invite codes. All of this will create a buzz about your product. When it comes to invite codes, have users submit their email addresses to be notified when more invites will be available. You’ll at least now have a list of people who have expressed interest in your app and they can be notified when your initial release comes out.

6. Become your own support department. Dealing with your users on a direct basis allows you to get into their mind and get instant feedback. The people who are developing the application should be answering questions, defending their choices and taking criticism. Be sure to consider a FAQ page and forums so that users can help themselves and other users.

I’ve really only scratched the surface of what this book has to offer. Check out the rest here!

HTML used to semantically describe what information looks like. HTML is now leaving the styling of information up to Cascading Style Sheets and is becoming more interested in describing what the data is. There are tags to let the browser know what information is a header, paragraph, list, etc. Microformats take the concept of describing data up a notch. Microformats are pieces of semantic data embedded into HTML that uses existing standards to describe what the information is. Once a user agent (such as a web browser) knows what certain pieces of data are, it can export the data to a more appropriate context. In this article we’re going to look at two microformats in particular: hCard, hCalendar.

Both hCard and hCalendar are based off of already existing standards (vCard - RFC#2426 and iCalelndar - RFC#2445 respectively). With some XSLT transformations or Javascript parsing, we can export the microformatted data in a webpage to other pages or into other data formats. For example, sites like upcoming.org mark up events with the hCalendar microformat. If we plan on attending these events, we can add it our Google Calendar, Yahoo Calendar, or 30Boxes to remind us about the event at a later date.

One of, if not the most popular microformat user-agent is the Firefox extension Operator by Michael Kaply. Currently, Michael is working on adding microformat functionality and javascript functions for microformats to Firefox 3. This means we’ll be seeing a lot of these features in the next version of Firefox. Operator supports a wide range of microformats, but as previously mentioned we’re only going to stick to hCard, hCalendar and we’re going to talk a bit about rel-tag. The premise of operator is simple: if it detects any microformatted data, it allows you to take some sort of action. If you find a person or place marked up with hCard, you can export it as a vCard or add to yahoo contacts. Exporting an hCard as a vCard will allow you to save a contact to programs like Address Book, Outlook or any program that supports the vCard standard.

I’ve already mentioned what you can do with information marked up with hCalendar, so let’s look at rel-tag. Rel-tag is simply marking up up the “rel” property of a hyperlink with the value “tag.” Once Operator knows that the link is a tag, it can then look for that same tag at sites like flickr, technorati, and del.icio.us. A common use for tags is looking up additional information about something you’re reading. Blog posts for example are usually tagged, so people can find pictures on flickr, related blog posts on technorati, or related sites on del.icio.us.

Let’s take a moment to recap and see why we like microformats and operator. For one we don’t have to input data ourselves. Since the data is already online we’re simply copying it to our application of choice. With this comes the advantage of actions becoming point and click. If you want to add an event to your Google Calendar, you point and click on the add to Google Calendar option. Pretty simple.

One area that can benefit from microformats is the cell phone market. I’ve already written about the iPhone as a microformat killer-app, but I wanted to expand this idea to include both cellular phones and internet-enabled PDAs. Cell phones and PDAs both have notoriously horrible input interfaces. Don’t you dread typing out a long text message, let alone trying to search for something on a cell phone browser? What about trying to write something out in Graffiti? What if these devices had the point and click ease of use that operator has? With REAL browsers coming to next-gen cell phones such as the iPhone, I see no reason why microformats shouldn’t be a part of this market. Imagine adding a person’s contact information into your cell phone via their hCard. You have all of the information you need about them ready to and be entered into your cell phone at the tap of a stylus. The same can be said about events and adding it to your calendar application on your cell phone or PDA.

With these smaller devices, ease of input usually suffers. In this case microformats make a great alternative to user input and can help overcome these shortcomings. It really can be just as easy as point and click.