ChasingSparks

Facebooker and Rails 2.0

If you are using the Ruby Facebooker plugin for developing Rails Facebook apps, you should note that the default cookie-based session storage engine is going to give you some weird errors concerning your Facebook session key being invalid or no longer valid. I assume that RFacebook would have the same problem, but I am just toying around, not seriously investigating Facebook development.

The obvious fix is to switch to a alternative session storage engine (e.g. active_record_store).

Mate1 on Facebook

Here is another reason why Facebook is not worth anywhere near what recent valuations have suggested. I logged into my account to partake in my socially voyeuristic morning ritual and was greeted by the following ad:

Yes, it is a Mate1 ad. For those of you unfamiliar, Mate1 bills itself as "The web's largest intimate dating site, with millions of members in the U.S. and worldwide. Sign up today, 100% FREE for women. Men pay a monthly fee." It's a casual sex website.

Google my accept money from adult-oriented advertisers, but the targeting is limited to people searching for a relevant term. Facebook pushed this ad on me because I am a young male. I would prefer not to see adult advertising on my "social utility".

Moreover, when was the last time you (and by that I mean a man in his 20s because that is what my experience is bound by) saw a Facebook ad for anything but an online dating site or novelty T-Shirts. The mini-feed ads are more diverse, but by now my mind has them so filtered they rarely enter my conciousness.

Facebook has peaked and is now on its decent. Long live FOAF and it's yet-to-be-seen replacement.

iGoogle Finance App gives Information is temporarily unavailable.

If you are getting a "Information is temporarily unavailable" from iGoogle's Finance App on a Google Apps Start Page and you are using your own domain, you won't ever see anything else. At first, I checked Googles help section and found a thread for this error message. From the thread: "The "Information is temporarily unavailable" message is most likely caused by a temporary problem with a third-party gadget provider. This issue is usually resolved quickly, so we encourage you to check back soon."

Okay, but this isn't a third party app and the message has persisted for 3 days. Doesn't seem right. Then I found an blog post for the announcement of this app on the Google Finance blog.

From the post: "But wait, there's more! If you're a developer, we just made it easier for you to make a stock market gadget with our new API. The gadget API for market data provides a framework so developers can display stock market information from the American, Nasdaq and New York stock exchanges within a gadget on Google properties. Unfortunately, due to data licensing restrictions, we couldn't open this API for display on any platform."

The iGoogle Finance App uses this API and, because my Google app uses it's own domain for the start page, it probably uses AJAX policy to prohibit my use (speculation because I don't care enough to look). So much for that.

Using :joins in ActiveRecord

I always seem to forget about the :joins option in ActiveRecord. It is incredibly useful for a certain class of not-to-often needed problems. Like DHH says, Ruby on Rail's will let you do anything but will impose it's opinions by making some things more painful.

Let's say I have the following models:

class Contact < ActiveRecord::Base   belongs_to :user   has_many :receipts end class User < ActiveRecord::Base   has_many :contacts   has_many :roles     # Roles in many different product lines end class Role < ActiveRecord::Base   belongs_to :user   belongs_to :product_line end

Now, let's say I have a receipt that says only which contact paid and the amount of money received, not which user made the sale (I am obfuscating what my app actually does with this salesman analogy.) I have to do a join from the contact table to the user table to the roles table (users can have identical contacts but may not necessarily be selling the same product). Basically, :include=>[...] won't work.

Instead, you use the wonderful little :joins=>... option.

... conditions_string +=' AND `users`.id=`contacts`.user_id AND `roles`.user_id=`users`.id AND `roles`.product_line_id=:product_line_id'         conditions[:product_line_id]=params[:product_line_id] @contacts=Contact.find(:all,             :conditions=>[conditions_string, conditions],             :joins=>',`users`,`roles`')

Don't Lend Friends and Family Money! Why?

I seem to be arguing with people a lot more these days.  In the past, I didn't argue often because I didn't care if I managed to change someone's opinion. What did that earn me? Why waste the effort?  Now, I argue a lot more.  I still don't care whether or not I convince a person that my side is right, but I have found that arguing tends to refine my own ideas and help prevent myself from falling prey to still-life mistakes.

Recently, a friend of mine said he, as a rule, doesn't lend family or friends money (I mean more than the amount required to buy a few drinks at the bar).  I strongly disagree with this rule.  In my own experience, I have often been a borrower from friends and family.  As a personal rule of my own, I repay debts and do so with interest. 

Now, I understand that some people might be afraid that if the debtor can't pay back the creditor, it could put strains on the friendship – a real possibility.  On the other hand, the borrower is certainly going to be grateful to the creditor, his or her friend, for showing a vote of confidence in them.  I think, in terms of the friendship, the effects of fear and gratitude nullify each other.

A much more poignant example is in funding a business venture.  If the person is a genuine friend of mine, I generally assume are more likely to pay me back.  The instinct of reciprocity is much stronger amongst friends.  Now, certainly, if I think the person is incapable of pulling off their chosen venture or that the chosen venture is bad, I will obviously say no (the former case being a much bigger deal-breaker than the latter). 

If I do think the venture is bad, I will explain why.  Actually, saying “I don't lend to friends and family” when you honestly mean, “I think your idea is bad” is a pretty shitty thing for a friend to do.  If my friend is completely smashed after a night spent with Jägermeister, I wouldn't let him drive home.  Same rule applies. If you value the well-being of your friends, you should step up and explain why you think their idea is bad, even if it momentarily offends them.

Also, I expect my reward for the risk taken to be commensurate with that which would be given to me by an anonymous entrepreneur.  Maybe that's due to the influence Atlas Shrugged had on me, but clearly, I am still taking a risk and should be compensated.  No, I am not going to lend my friends money at the bar and then calculate the interest owed two day's later.  That would be offensive and cheap in the bad sense. I didn't really forgo any possible profit in those two days.  That money was in my wallet or on my credit card.  In both cases, the amount being so small, it wasn't on it's way to my brokerage account.

I guess what I am trying to say is, “Don't let friend do dumb things without objecting.” If a friend has a good idea and they are capable, it's a good investment.  If the idea is bad, tell them.  If the friend has a good idea, is capable, and is not respectable….why are they your friend?

Ordering error_messages_for in Rails

Due to laziness, I have not, in the past, given much back to the open-source community. I would like to start doing so.

For the most part, I think Rails is an elegant solution to web application development. That is why I find it shocking that error_messages_for is still unordered due to hash storage. It is a pet peeve of mine to get a form with multiple errors that do not match the order presentation by the form. It just seems sloppy.

Anyways, I took the time to write a plugin named ordered_error_messages_for. It extends the core so that if you supply :order=>[:attr1,:attr2, …] to error_messages_for(…) you get a clean orderly display of errors.

Example:

error_messages_for(:user, :order=>[:name,:password,:phone_number])
error_messages_for(:user, :order=>{:user=>[:name,:password,:phone_number]})

Install it with a:

./script/plugin install http://orderederrors.rubyforge.org/svn/ordered_error_messages_for

More information at:
orderederrrors on RubyForge

Sexy. Rails Sexy.

Sharding with Cookie-Based Sessions

I used Rails 2.0 as part of my recent startup venture (actually, I started with 1.2.3 but migrated 2 days after the new release).  The cookie-based session storage was my primary motivation for using the latest release before it has been hardened by wide deployment.  Cookie-based session storage is sexy.  They appropriately move session storage to the user through the utilization of HMAC.  In other words, no scalability bottlenecks will be imposed because of PStore and ActiveRecord sessions.

While the decision to make Cookie-Based session storage the default session storage engine in Rails 2.0 still seems to be a bit controversial, the benefits, assuming security is maintained, are incredible.  In my venture, I used sessions in a way that many developers would find dangerous.  My venture was a dating website targeted to large metropolitan areas, each with it's own sub-domain.  The website emphasized finding people to go on a date with in real-time.  Offline users were not browsable. Users were grouped by metro shard: New York City residents would go to the nyc sub-domain, Philadelphia residents would go to the philly sub-domain, etc.  All of the user's profile information and messages was stored on server pointed to by the primary domain, but once logged in and ready to interact, the user would be dispatched to the appropriate shard.

Here's where things get…unique. Instead of doing MySQL replication to each shard, each shard had its own, unshared database.  When a user decided to interact in a specific metro area, the user clicked a form, disguised as a hyperlink, which submitted their encrypted profile to the appropriate shard.

For example, if the user wanted to find a date in Uptown Manhattan, they would click the Uptown Manhattan link, which did a post to the nyc shard, Uptown Manhattan homepage, sending the encrypted profile silently along.  The nyc shard then checked for tampering, decrypted the profile, and stored it in it's local memory only database.  If the user had had been idle for too long the profile was marked as stale, and a chron job would sweep it away shortly thereafter.

This technique is only worthwhile if there is something that can be sharded but there are clear benefits. The main server handled all permanent changes to the user's data (including message sending) but this was done via posts and redirects.  The main server and each shard were completely decoupled.  They did not, at any point, communicate with each other.  Obviously, this makes for a very scalable website.

I should note that by using this technique I was committing the dual sin of premature optimization and abuse of something cool for the sake of messing around.  That makes me dumb.  My point is, if you have a mature project that is running into scalability constraints but has a possibility for sharding, this technique could be valuable (or at least cool).

List people

We all know list people. They enumerate every task and derive great satisfaction from being able to mark an item as complete.  I have, in the past, looked down upon list people.  I thought their obsession with lists was a personality flaw that inhibited them from being able to work on-the-fly.  Recently, as anyone who reads this blog might know, I have been reevaluating all of my premises given the failure of my recent startup venture.  I think my aversion to, and view of, list people was one of my faulty premises.

Part of that realization stemmed from a conversation that resulted in a blinding rage.  A friend of mine was trying to convince me that you can not learn from books.  She said you can only learn by doing, and books are just noise.  I read obsessively because of an agreement I have with Sir Francis Bacon.  Part of her reason for saying this might have been because the conversation was political, and as we were on different sides of the issue, she was personally attacking me.  It happens.  Anyway, to defend my view of books I not-so-calmly tried to explain to her that people who hold such a viewpoint read books passively.  If you are not continuously evaluating and challenging what the author is saying, then yes, a book's value is greatly reduced (as is reading only books you agree with before reading).  If you read a book actively, taking time to devour new points of view while being able to call “Bullshit”, then a book is a learning device with incredible bandwidth.  I read actively.

This brings me back to my misunderstanding of lists as a practical tool.  If you use a list as a passive device, it is of little value.  It just enhances what may be a rigid personality.  Alternatively, if you use a list as an active device there is a great benefit.  For example, I have always scoffed at things like an Entrepreneurial Check List because I thought they were offensive to creativity. I was wrong. If you actively evaluate your idea/project against a check list with the intention of challenging your own assumptions, you will be more likely to succeed.  Again, if you're a rigid person and use such a list as a passive tool, as in “my idea must pass every test”, it's just silly whereas if you use it to question the validity of your own ideas, it's incredibly valuable.

Fixed faulty assumption…check.

AdWords Traffic Estimator Inaccuracies

I mentioned in a previous post that AdWords can give you misleading estimates of both available traffic and CPC pricing. Before initializing a campaign I used the Google AdWords traffic estimate tool. The following is a partial screenshot of it's estimation.

As show, given a CPC rate of $0.12 and a daily budget of $10.00, I would receive all the clicks I requested. Satisfied, I created a new AdWords campaign and inputed the exact same parameters (both were targeted to the US alone). To my surprise the results were very different.

Okay, wait...0 predicted clicks? At the top of the page there was an explanation for the discrepancy.

The fact that I had never had a campaign meant my estimates would be rough. Makes sense but wouldn't account for 0 clicks. The next bullet point did. Only Google's search result ads are included in the in-campaign estimator. I assumed Google would deliver ads as predicted by the traffic estimator tool but since it was in the campaign, they didn't indicate estimates of the content network.

Unfortunately, only a few clicks ever came through. I emailed Google but their response was vague. If it was another company I would suggest it was a form of baiting. On the other hand, I wouldn't accuse Google of poor programming.

The deviation is greater when you target a geographically expensive area (e.g. New York City). From the looks of it, they are using the system-wide average instead of geographic average resulting in a gross underestimation of cost.

Starting an Online Dating Network

(My experience with Tryst.com)

Dollar Bills Ya’ll

Markus Frind's free online dating website, Plenty Of Fish, earns around five million dollars a year in advertising revenue.  Andrew Conru's FriendFinder Inc was recently bought by Penthouse for $500,000,000. SparkNetworks, of JDate and American Singles fame, is on the market in the $100,000,000 area. Obviously, I was attracted to the online dating industry because of the proven profit potential. People are willing to pay for online dating.

Metcalf’s Law

Unfortunately, I learned through failure that this profit is hard earned. Let's pretend that you have created an algorithm that is 100% efficient at matching people. In other words, if the algorithm matches you, it has mathematically found your soul mate. This is all well and good but you are still bound by geography. Clearly, if the algorithm matches a person in Guam to a person in Brooklyn it is of no value. Even the person who is completely dedicated to finding their supposed soul mate is not likely to travel more than 50 miles.

On the other hand, let's say you don't claim to match users but only offer the ability to search by whatever criteria you find important. This is roughly what Markus Frind does. His website might not be flashy or use unnecessarily complicated math, but it has claim to a tremendous set of users. Additionally, with the exception of age, gender, sexuality, education, and appearance, most factors are going to be garbage in, garbage out.

The important thing to note is that in both cases, match making and browsable profiles, the websites value is derived from the size of its user base. Metcalfe's Law is a bitch. While I, like many people, was attracted to online dating because of its proven profit potential, I misread the costs of entry. Programming, hosting, and bandwidth are all so negligible that they are not really relevant. The advertising dollars needed to reach a minimum level of geographical saturation are extremely high and often overlooked. In the beginning, given the low conversion rate resulting from a low saturation, you are not going to feed AdWords and earn a profit. In other words, my mistake was the oft repeated one of under-capitalization. Unless you have a brilliant idea combined with a bit of luck or say, a couple hundred thousand dollars in burnable cash, an online dating venture is unlikely to succeed.

A History of My Projects (learn from my mistakes)

Version 1

The first version of Tryst was targeted to American users with no part of the site externally visible – as in viewable without login – except for the tour and signup page. The concept was to have a Craigslist style dating network where users posted “Trysts” (dates they want to go on). There was no free tour. The website converted terribly (read: no users). Clearly, if the user is going to pay for an online dating website, they expect a free tour because nearly every website offers one. No matter how good an offer may appear, there should be a free tour.

Version 2

Realizing that the advertising costs needed to reach a decent saturation of users was going to be well beyond my budget, I set out on creating a free, advertising supported network that could be fed by search engine hits. Again, I was interested in creating an “I want to go on this date” oriented network, as it was at least, an underdeveloped area in the online dating industry. The search results did slowly advance but after two months I was only earning around $10.00 a day in advertising.

Version 3

Discouraged by the slow growth of Tryst Version 2 and apprehensive about the possibility of a bubble in PPC advertising, I set out to create Tryst version 3. This version was also tried to create real world dates, but in a different way. Users would login and be presented with only online users that matched the gender, sexuality, and age group they were interested in. They could then send messages back and forth in an instant message / conversational way. This version was not free but did have a form of baiting. You could see the profiles of other members, but you could not message them unless you had a paying account. Free members could respond to messages sent by paying members, but they could not initiate the conversation.

This version actually had a high visitor to free member rate (between 20 – 35%). Unfortunately, my estimates of the CPC costs for Google’s geographically targeted visitors were erroneous. I was assuming (using Google's estimator tool) a PPC rate of between 40 cents and 1 dollar. At this rate, I also assumed I could expect several hundred visitors per day, per city (also from the traffic estimator tool). In reality, targeting NYC costs a minimum of around $1 CPC and, more alarmingly, generated only a couple clicks a day. Tryst version 3, like versions 1 and two, could not work.

Advice borne of failure

• The barriers to entry in the only dating industry are, in fact, very high. You are in a race to acquire new users before your old users are discouraged. Until you reach a certain point of saturation, you are going to be burning advertising bucks.

• Do not base your costs on one set of estimations. I used only AdWords's Traffic Estimator tool which severely underestimated the CPC and available traffic leaving no chance of success with my chosen business model.

• Do you really want to make an online dating website? I really had no interest but was attracted by the low entry cost and proven profitability. I found both assumptions to be false and more importantly, because I wasn’t interested in solving any problems in online dating, had little continuing motivation.

• If you do decide to start Yet Another Online Dating Website, be original! PlentyOfFish created a free network for online dating when the industry had none. EHarmony was one of the first networks to offer comprehensive matching (aka voodoo but still). I believe the future in online dating is going to be more real world date centric. Find ways (and funding) to get people out and dating with people they could potentially enjoy.