Simple, right? I sure wasn’t going to go reinvent the wheel by writing my own CSS for them though. Thankfully after searching for a bit I came across SimpleBits’ Mini Tabs. I didn’t want mini-tabs, but the HTML and CSS was remarkably clean. Only 4 CSS declarations on a simple HTML list with a class=”active” for the current tab. With some modification to the CSS I was able to come up with tabs that looked like the above (even looks good in IE7, amazingly).

So, if you want some decent looking/functioning tabs go yank the HTML/CSS from the above link.

Let’s get an example registration app set up:

rails registration
ruby script/plugin install http://svn.techno-weenie.net/projects/plugins/restful_authentication
ruby script/generate authenticated user sessions

Cool, now you have your registration app set up with a Users model, controller, and view. If you start up your server and head to http://localhost:3000/users/new/ you should see a very basic registration form. Let’s add our Address model. For the sake of brevity, I’m just going to create a field that references the User model and one field for a zip code, but you get the idea.

ruby script/generate model Address user:references zipcode:string
rake db:migrate

With our Address model in place, we need to let the User model know that it is linked to the Address model. Here’s what the User model looks like (\app\models\user.rb):

1
2
3
4
5
6
7

require 'digest/sha1'
class User < ActiveRecord::Base
  # Virtual attribute for the unencrypted password
  attr_accessor :password
 
  validates_presence_of     :login, :email
  # lots more stuff that we're not going to worry about...

We’re going to add three things:

1
2
3
4
5
6
7
8
9
10
11

require 'digest/sha1'
class User < ActiveRecord::Base
  has_one :address
  accepts_nested_attributes_for :address
  attr_accessible :address_attributes
 
  # Virtual attribute for the unencrypted password
  attr_accessor :password
 
  validates_presence_of     :login, :email
  # lots more stuff that we're not going to worry about...

We’ve told the User model that (1) it has one Address model, (2) that it should save data for Address automagically, and (3) that the address_attributes fields are permitted fields to receive data for (if you read through the code a bit further you’ll see another attr_accessible line, you could add address_attributes there too).

We need to make one change to the User controller (\controllers\users_controller.rb) to prevent an “Called id for nil” error later on. At line 6 you should have an empty new method. We’re going to create an instance variable for User:

6
7
8
9

  # render new.rhtml
  def new
    @user = User.new
  end

Let’s now take a look at the one User view that restful_auth created (\app\views\users\new.html.erb):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<%= error_messages_for :user %>
<% form_for :user, :url => users_path do |f| -%>
<p><label for="login">Login</label><br/>
<%= f.text_field :login %></p>
 
<p><label for="email">Email</label><br/>
<%= f.text_field :email %></p>
 
<p><label for="password">Password</label><br/>
<%= f.password_field :password %></p>
 
<p><label for="password_confirmation">Confirm Password</label><br/>
<%= f.password_field :password_confirmation %></p>
 
<p><%= submit_tag 'Sign up' %></p>
<% end -%>

First of all, we need to change the form_for :user to be form_for @user. Second, we get to add in our zipcode field:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<%= error_messages_for :user %>
<% form_for @user, :url => users_path do |f| -%>
<p><label for="login">Login</label><br/>
<%= f.text_field :login %></p>
 
<p><label for="email">Email</label><br/>
<%= f.text_field :email %></p>
 
<p><label for="password">Password</label><br/>
<%= f.password_field :password %></p>
 
<p><label for="password_confirmation">Confirm Password</label><br/>
<%= f.password_field :password_confirmation %></p>
 
<% @user.build_address unless @user.address %>
<% f.fields_for :address do |a| %>
  <p>
    <%= a.label :zipcode %>
    <%= a.text_field :zipcode %>
  </p>
<% end %>
 
<p><%= submit_tag 'Sign up' %></p>
<% end -%>

Here’s where I ran into the two gotcha’s. If you don’t switch form_for :user to form_for @user when you submit the form you’ll get a very unpleasant error that looks like this:

ActiveRecord::AssociationTypeMismatch in UsersController#create
Address(#46729050) expected, got HashWithIndifferentAccess(#23561230)

Second, if you don’t add in line 15, @user.build_address unless @user.address, you’ll get the following error when you try to view the form:

You have a nil object when you didn't expect it!

More info on why that error occurs here.

Anyway, with the above steps you should now have a registration form that creates records for both User and Address. If you found this helpful, leave a comment and let me know!

Whenever I was watching more TV than working on my Great Idea, it was because I was stuck. I didn’t realize it at the time, but my mind was avoiding making a tough decision or working through a particularly hard problem. My Internal FUD pushed me towards easier tasks. Watching TV was a whole lot easier than spending a couple hours researching, thinking about, and making the tough call. –7 lies that prevent your great idea from becoming a real business

Whenever I find myself not working on my project I come back to this quote, because it’s always true. Anytime I’m not working on scotchel.com for any significant amount of time it’s because I’ve hit a roadblock. My current issue can be stated simply: do I continue building the site in PHP or do I switch over to Ruby on Rails?

The answer has been hard to come by, perhaps because I haven’t really sat down to think about it. But I was tired of being “stuck” so I spent an hour this morning reviewing why I might want to (or not want to) switch to Ruby. And, as of now, I’m going to make the switch to Ruby. I’ll try to get to the same place I left off in PHP (at the very least) and we’ll see how it goes. From what I’ve read, it should be both easier and more fun, so I’m looking forward to it.

I read their book recently and one piece of their advice that really stuck with me is to solicit early. They say that one of the best things you can do for yourself is to start collecting email addresses and get a base of people going that will become your early adopters.

With that thought in mind I created a teaser page for scotchel.com. You should take a look at it and add your email address here.

So with my fourth search page mockup I set out to try something a bit different and I came up with panels or “cards” for each person. The same information as before, just rearranged a bit. And I also replaced the stars with “I like them”/”I don’t like them” buttons because that seemed a bit more intuitive (how do you rate person on a 5-point scale?).

Fourth search page mockup

While I was in the process of drawing up these mockups I ran across a page on Google which shows a heatmap for the best locations to place ads. Ads on the top right side have weak performance and ads on the bottom right side have (apparently) no performance. With that in mind I decided to ax the ads on the right side to free up some space there and instead place ads intermixed with the search results. I’m still not sure that’s the best idea or the best location, but it seems better than wasting a bunch of space on the right side.

Fifth search page mockup

Further reading about the usage of dating sites led me to realize that the majority of people place a lot of importance on photos (as superficial as that may seem). I thought about various ways to make people’s photos take up the majority of the space rather than a bunch of text, and I think I was successful with this mockup. Something about layout out results in columns and rows freaks me out a little though. And I can’t quite figure out why because reading left to right and row after row is how we read text (in most languages, anyway).

Sixth search page mockup

Finally I decided to return back to the row layout and see what would change if I added some space on the right by removing ads. I also took out the “profile” and “message” links because a) profile seemed worthless when you could just click on their name/photo and b) message seemed a little premature if you hadn’t looked at their full profile yet. With these few changes I was able to add a lot more space for the description text… and not much else. It is a better layout, just not by much.

Seventh search page mockup

What did I learn from all of this?

• Photos are king, and should take up the most space
• The row based layout isn’t an ideal format for showing profiles
• I can kill the profile/message links without any (foreseeable) adverse effects
• The ads on the right side need to go

Some good learning going on there. Not a bad investment of time at all.

After searching around for a bit I came across this nice bit of code which creates a MySQL query using PHP variables to calculate the distance. By combining the two methods I was able to create a very workable solution for sorting by distance. Here’s what I did:

First, download the zipcode SQL from Micah’s page and run each SQL file. That should give you a new shiny table called zip_code filled to the brim with (what else?) zip codes.

Second, you’ll need the get_zip_point function from Micah’s code:

/**
 * This function pulls just the latitude and longitude from the
 * database for a given zip code.
 */
function get_zip_point($zip)
{
	$sql = "SELECT lat, lon from zip_code WHERE zip_code='$zip'";
	$r = mysql_query($sql);
	if (!$r)
	{
		$this->last_error = mysql_error();
		return FALSE;
	}
	else
	{
		$row = mysql_fetch_array($r);
		mysql_free_result($r);
		return $row;
	}
}

Third, you’ll want a function to generate the SQL you’ll use in your query:

/**
 * Returns the SQL to calculate distance based on latitude and longitude
 */
function get_distance_SQL($lat, $lon)
{
	$sql = "
	3957 * 2 *
	atan2(
		sqrt(
			pow((sin(0.0174*(lat-$lat)/2)),2) +
			cos(0.0174*$lat) * cos(0.0174*lat) *
			pow((sin(0.0174*(lon-$lon)/2)),2)
		)
		,
		sqrt(1-
			(
				pow((sin(0.0174*(lat-$lat)/2)),2) +
				cos(0.0174*$lat) * cos(0.0174*lat) *
				pow((sin(0.0174*(lon-$lon)/2)),2)
			)
		)
	)
	as distance";
 
	return $sql;
}

Fourth, you wrap it all together with a few lines of PHP. I’m using CodeIgniter to handle the SQL call, so your mileage may vary a bit on the exact implementation details.

list($lat, $lon) = $this->get_zip_point($user_zip_code);
 
$this->db->select("users.username, zip_code.city, zip_code.state_prefix," . $this->get_distance_SQL($lat, $lon), FALSE)
		->from('users')
		->join('zip_code',"users.zip_code = zip_code.zip_code")
		->order_by('distance', 'asc');
 
$search_results = $this->db->get();

And shazam, you now have a way to sort a set of SQL results by distance.

Let’s assume there’s a straight girl that wants to find guys that would be interested in her. Obviously her pool of candidates includes straight guys. However, it’s also entirely possible that it would include bisexual guys. After all, they’re interested in girls too.

It gets even more complicated with bisexual folks. If you’re a bisexual guy you may be interested in gay guys, bisexual guys, straight girls, and bisexual girls. If you have gender and orientation as separate fields in your database you’re suddenly searching on 8 different elements:

• gender = “male” AND orientation = “gay” OR
• gender = “male” AND orientation = “bisexual” OR
• gender = “female” AND orientation = “straight” OR
• gender = “female” AND orientation = “bisexual”

Yikes. I came to realize that the easier way to do this would be to merge gender and orientation into one über field (gender+orientation). In effect this allows you to always halve the number of elements you have to search on.

I created a quick logic table to figure out how I could get it to work:

	Straight Guys (1)	Gay Guys (3)	Bisexual Guys (5)	Straight Girls (2)	Gay Girls (4)	Bisexual Girls (6)
Straight Guys (1)
Gay Guys (3)
Bisexual Guys (5)
Straight Girls (2)
Gay Girls (4)
Bisexual Girls (6)

Searching now becomes a lot more straightforward. If you’re a 1, you’re looking for a 4 or 6. If you’re a 3, you want a 3 or 5. And so on and so forth. Another nice part of this system is that you can get the gender by doing a simple modulus operation. Divide gender+orientation by 2, and if the remainder is 1 you’re a guy and if the remainder is 0 you’re a girl.

That got me to thinking, are there other places where I could be merging data together to save myself a headache? I scoured through my database and there were a couple places where I could merge some booleans together into a single field using a truth table, but I wouldn’t gain anything extraordinary from it. Anyhow, it’s a good tool to keep in the back of my head in case I run into similar situations in the future.

On the (perhaps) not so good side, the majority of that time has been spent implementing pagination on the search results page. You would think this would be incredibly easy considering that CodeIgniter has a Pagination class. It shouldn’t take me approximately 8 hours, right? Well, apparently it does when you’re trying to use AJAX to handle your pagination. I was even perfectly willing to accept a complete hack for a solution, but alas, anything I tried to do to cobble together a fix for one issue only introduced another issue somewhere else.

Eventually jQuery came to my rescue. In the configuration for Pagination I set the base_url to ” (an empty string) so that the href on the pagination links would contain only the number for the search results. Then I set up jQuery to find all of the anchor links in my paging div, stop the normal link function, and call my function to load in the search results. The jQuery code came out like this:

1
2
3
4
5
6
7
8

$(document).ready(function(){
  $("div.paging > a").click(function(e){
    // stop normal link click
    e.preventDefault();
 
    $('div#search_results').load("/search/get_results/"+$(this).attr("href"));
  });
});

This is still something of a hack as I’m basically creating fake href values for the anchor tags, but whatever, it works! I can come back later and fix it. At this point hacks are okay. Speed is much more valuable than perfectly elegant code as I want to find out if my idea is solid before investing oodles of time in it.

I wanted to be able to create a bar that would have a left and right portion on top, with a second connected portion on bottom. I also wanted a border around the outside of it with a border dividing the top and bottom portions. Kayak uses a table for their layout but I wanted to see how I could accomplish the same thing using divs and CSS. After a lot of trial and error I was able to come up with the following:

Here’s the HTML for it:

1
2
3
4
5
6
7
8

<div class="bar ui-corner-all">
<div class="top-left">
  Top left</div>
<div class="top-right">
  Top right</div>
<div class="bottom">
    Bottom</div>
</div>

The ui-corner-all class is from jQuery UI, but otherwise you’ll see everything else in the following CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

.bar {
  border: solid 2px #dedede;
  width: auto;
}
 
.top-left {
  padding: 3px 5px;
  float: left;
}
 
.top-right {
  padding: 3px 5px;
  text-align: right;
  float: right;
}
 
.bottom {
  padding: 3px 5px;
  border-top: solid 2px #dedede;
}
 
.clear {
  clear: both;
}

This works great for Firefox, but as I was creating this post I figured I’d try it out on IE and noticed that I get some extra space in the top section:

I’m not sure what’s causing that, and I’m not going to try to figure it out at the moment. I’m saving all of that for the very end as I doubt this is the only IE-specific issue I have and I want to tackle them all at once. If I figure it out though, I’ll be sure and update this post.

1
2

$this->form_validation->set_rules( 'username', 'Username',
  'trim|required|callback_username_check' );

And then create a matching function like this:

1
2
3
4
5

function username_check( $username )
{
  // some code
}
?>

However, as this is currently implemented someone could access your function as a page at a URL like example.com/index.php/login/username_check/ if they guessed the function name. While that may not have any ill side-effects, it’s probably just as well if no one can access the function besides you.

In come private functions for controllers, which allow you to create a function like this:

1
2
3
4

function _utility()
{
  // some code
}

And if you try to access the function via a URL, like example.com/index.php/login/_utility/, you’ll get a 404 (page not found).

You probably see where I’m going with this. If you create your callbacks as private functions, no one will be able to access the callbacks as pages. It’s quite simple to do. You add an underscore before your callback function name:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function _username_check( $username )
{
  $valid_username = TRUE; // You would perform some kind of check on the field here
 
  if ($valid_username == FALSE)
  {
    $this->form_validation->set_message('_username_check', 'The username you have provided is not valid.');
    return FALSE;
  }
  else
  {
    return TRUE;
  }
}

And then add an underscore in your callback rule (note the two underscores after callback):

1
2

$this->form_validation->set_rules( 'username', 'Username',
  'trim|required|callback__username_check' );

Done!