As I was writing my last post about the arms race between the client and the server, a thought crossed my mind.
Why has the social networking arms race come down to Facebook and Google?
Facebook is #2 in the social networking space and Google is #I-don't-care. Why? Because Google doesn't have a viable social network.
Don't bother with Gmail, YouTube or Okurt.
Okurt isn't in the same league as Facebook. Just trust me on this.
Gmail, YouTube and whatever other Google properties aren't social networking sites. Just don't try to make that argument.
That's like saying Hotmail, the LA Times or Amazon is a social network. Stop it.
So then I read the Cold War comparison( more here ), and I realized it was very exaggerated and not really true, but made for an interesting headline and topic. (Well played, Duncan, well played).
So Google is trying to tip the dominoes. With the release of OpenSocial and FriendConnect, Google is trying to get other countries, er, ah, sites to join them and thrust itself into the social networking scene. As more fall, more will be more likely to fall, or something to that effect.
The problem is, Google is shooting blanks, and Facebook is still firing back, playing right into Google's hands.
Google opens. Facebook opens some more. Google opens even more. Facebook... you get the point.
The difference is, people actually care about, and can build applications around Facebook's openness.
It's like poker, but not. Google is getting Facebook to go all in, but Google is playing with house money. Why should they care if they lose?
On the other hand, if Google can accumulate second-tier sites and entice Facebook into blowing open it's doors, there is an open conduit from Facebook to thousands of other sites, and that conduit is Google.
If I were Facebook, I'd call Google's bluff before I lose the only thing valuable I have.
So TechCrunch confirmed that Facebook will be turning their application framework into an open-source project, meaning that pretty soon, anyone who wants will be able to host Facebook Apps on their own site.
The details are still scant at this point in terms of what features will be available and how it could/should/would be implemented.
But I'm guessing it's going to be pretty much exactly like OpenSocial.
With one rather enormous exception.
Facebook Apps rely on server components. To make Facebook Apps stupidly simple. A Facebook server makes a request to your server, your server returns markup and wawmo, you have a Facebook App. What you want your server to run is up to you. The Official (cue the Choir and sunrise) API is implemented in PHP, but has been ported to ActionScript, Ruby, Java, blah, da, blah, blah, blah.
OpenSocial requires no servers -- aside from the one(s) acting as the host/shell/container/whatever-you-want-to-call-it. So, in theory, and I guess, in practice, you could build an entire OpenSocial app with no server, relying completely on client-side Javascript. And really that's your only option.
Now, pros and cons aside, many have wondered whether Javascript is the wave of the Web X.0 future because of it's ubiquitous nature and nearly absolute install base.
If OpenSocial with its client-side glory comes out on top, it would go a long way in proving that is true.
Like many web developers I am largely self taught. The web is full of endless resources and anyone with an internet connection and Google can more or less figure anything out.
Having said that, it often times does help to have a course provide structure as a guideline to your learning. I found a course that is online and free to anyone that wants to learn the basics of Ruby.
You can find it here: http://www.rubylearning.org/class/
You can also check out the notes here: http://rubylearning.com/satishtalim/tutorial.html
I haven't taken a computer science course in over a decade so this course helped get me back to the fundamentals of programming and specifically how they relate to the world of Ruby.
The individual that puts the course together has an active twitter account and is easily accessible on the course message boards and via email.
I've been going through the many resources I've used over the past several months to get up to speed on RoR and will start posting more of them here on this blog going forward.
This post is partially a response to Steve Gillmor's article Facebook's Glass Jaw and partially a response to Cody's earlier post on the same subject. I firmly believe that Facebook should allow users to export their friends data elsewhere as well as many other pieces of PII. Of course the legal ramifications of such a decision would have to be investigated in depth, but in reality I own my friendships, I own my personal information, and if I want to share said data Facebook really shouldn't try to stop me.
And yes users and user information is core to Facebook's revenue stream, but friends, events, photos, etc. aren't. Facebook makes money - it does make some money - from targeted advertising based on, I'm assuming, usage patterns and Facebook-specific information, e.g., your networks, your groups, your activity. Now I'm not talking about exporting any of that. I'm not saying Facebook should share "Here's Dary. He's 24. He's a male. Oh and he likes movies and lives in Los Angeles so serve him ads for NetFlix and Fandango movie listings." Nor am I saying Facebook should create a Twitter-like API for friends' Facebook activity. I'm talking about Facebook distributing information that I have taken time to put in myself, information that is mine. I'm friends with Jorge Mir. What's the harm in letting Google and MySpace now that? If I can have my Jorge friendship show up elsewhere do I stop using Facebook altogether? Definitely not as I mostly use Facebook for viewing friends' activity, photos, and using applications, which leads me to my next point.
The privacy argument is, to put it bluntly, a joke. There is no difference between clicking a box that says "Share some of my information with other sites" and clicking the one that says "Know who I am and access my information" when adding an application on Facebook. This BBC article brought to light just how much personal information you get from a user adding your application. And as Facebook raises worries about Google or someone else sending PII to a completely random, potentially malicious, recipient all I have to say is, "That's exactly what you're doing!!!" There's no real oversight of Facebook applications. If a user adds it and chooses to share PII with it, then it's pretty much fair game to store as much user data as you want in a db somewhere (obviously against the TOS, but I'm pretty sure ne'er-do-wells couldn't care less). It clearly ain't that hard to collect massive amounts of PII using Facebook.
So why won't Facebook let me take my information elsewhere? Because it hurts the business? Not really. I'm sure most people would spend just as much time on Facebook, it'd just save them from having to find their friends all over again on a new site. Because of the privacy issue? Please. Checking a box to share some of my PII is no different than what they're doing right now with applications. As Facebook becomes more and more of a walled garden and the adoption of OpenId and Friend Connect becomes more widespread, I actually will consider leaving Facebook because I'll just get too frustrated re-entering the exact same information and re-finding friends over and over again.
In Conclusion,
Give 'em my data!
UPDATE: Further evidence of PII leaking from facebook: Facebookâs Friends Data Has Already Left the Barn
If you read my previous post on YSlow!, you know we made every attempt to assuage the YSlow! gods appeasing their insatiable appetite for efficiency.
So, we configured our S3 buckets to serve gzipped CSS and JS.
Unfortunately, we didn't account for how horrible the IE browsers are.
We began getting emails from folks in our Bristol offices with screen shots of pages that looked like the CSS hadn't loaded.
We booted up Parallels and had a look, and both IE6 and 7 looked fine to us. So we sent the usual replies: Try clearing your cache, it must be a setting you have on, upgrade your browser, etc, etc.
You see, we don't use PCs and we don't use the network, which just about everyone else in Disney uses. We have clean, unfettered, beautiful access to the Internet, so this problem seemed like it had to be bunk.
But then we started seeing user reports of the same thing. So I got my Google on and started researching gzipping assets and IE. There seemed to be some stuff related, but not a sliver bullet, and nothing that could explain why our IEs were fine and Bristol's weren't.
Then I remembered some of the pure wackiness that we endured on the network when I worked in Bristol. So we blew the dust of a Thinkpad Laptop, which was connected through our network, and brought up Fan Profiles on IE6.
Booyay! It was like National Turn CSS and Javascript Off For A Day, and we were failing miserably at it. Oh, Firefox and Safari and Opera were fine, but that's to be expected.
I didn't really know what to do because we had seen pretty serious page load gains from gzipping our content.
In the end, we decided at least temporarily, to not gzip, so we rolled back, and problem solved.
Interestingly, at the same time, our CNAME request for serving assets through Akamai completed. When I set up the configs for Akamai, I requested that it gzips the content.
So in theory, the content was being gzipped again. Even more interesting, IE on the network still looked fine.
YSlow! was happy. The network was happy. I was suspicious.
Was the content really being gzipped?
I looked around for a while to find out how I could test this. To save you time:
curl -I -v --compressed -A "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" http://a0.espn.go.com/javascripts_c/main.js?1210961500
And yes, it was being gzipped.
So for reasons I still don't understand, IE + corporate network + Gzipped content from S3 != E + corporate network + Gzipped content from Akamai, being sourced from S3.
Below you will see two YSlow! screen shots. One is good and one isn't.
I've been a huge fan of YSlow! and following its suggestions since it came out, but actually implementing these suggestions on a site the size of ESPN.com can be very difficult, especially since, until recently, ESPN.com has chosen flair over speed.
But with our opportunity to start over with Fan Profiles and Widget Center, we have made every effort to abide by the YSlow! way.
As you can see, we were just lower than an A, and we have one more change to roll out that should finally get us there, which is really exciting.
The hardest part is reducing dns look ups because there are so many different javascript files that are brought in through analytics, sponsored links and advertising that are beyond our control.
Any way, I'm proud of the team for sticking to this and making it a priority, and it has helped lower our page load times as well.
The blogs plunged from euphoric to despondent over the last 48 hours as MySpace, Facebook and Google all announced some sort of outside-the-wall sharing of their social graph data. See Here, Here and Here for a sample.
The tenor began to change as more information became available, hitting a low point with Facebook's blocking of Google's Friend Connect. See Here, Here and Here for a sample.
Is this news really surprising to people?
As a social networking fan and advocacy of openness, I say "that's garbage."
As an employee for a large company and an MBA student, I say "duh."
The first big issue with this initiative is Personal Identifiable Information. What PII data actually is varies, but is generally, first name, last name, email address, etc. Anything that could be used to identify the real "you".
PII is a really dicey issue in big companies, so much so that we have problems just transferring it from one server we control to another. Forget about trying to share it with, well, anyone.
Secondly, the incentives for the consumer is obvious, but what is the incentive for the business units?
OK, maybe Google is more willing to share their users info because this doesn't represent its core competency. Same with MySpace (owned by Fox). For these BUs, the publicity and potential attraction they get might be worth it (although, I still don't see it).
But what about Facebook? Facebook's sole business is its users and users' information. Why would it want to just give its business away to its competitors.
Sure, I'd love to have my Facebook friends in my Gmail address book and vice-versa, but I don't expect it to happen any time soon or ever.
And I get that.
I tried to use Ruby's built-in Active Record fixtures module to import an Excel-exported CSV file. No dice. Kept getting cryptic errors about improper formatting. Whoops. So then I installed this wicked cool gem named FasterCSV and piggy-backed off of this migration import script and everything went great. So for all those people with ancient (and kinda useless) Excel data files, now there's a relatively quick and painless way to import them into SQL dbs. Here are the steps I went through:
Install the gem:
sudo gem install fastercsv
Now I have several tables in my College Football spreadsheet and for this example I'll use the one with ratings data for College Football games. Each entry has a game_id, region_id (for the various regions where ratings data comes from, e.g., Atlanta and Austin), a rating, and a duration in quarter hours (since some games are only cut-ins, e.g., Georgia Tech-Georgia ends early and the Atlanta region picks up the last half hour of the Texas-Oklahoma game). So here's the script that imports my gross Excel spreadsheet into a useable SQL table - db-agnostic by the way (How do I love thee Rails? Let me count the ways.)
require 'fastercsv'
class LoadRatingsData < ActiveRecord::Migration
def self.up
FasterCSV.foreach("#{RAILS_ROOT}/db/migrate/fixtures/ratings.csv", :row_sep => "\r") do |row|
id,game_id, region_id, rating, duration = row
Rating.create(:id => id, :game_id => game_id, :region_id => region_id, :rating => rating, :duration => duration)
end
end
def self.down
end
end
And it's just that easy. Another cool thing, that I haven't done yet, is that you could take that one bulky Excel sheet that has way too much information in it, break it into useful models, and form actual relationships between the data. What a novel idea!
In Conclusion,
This rules!
I wrote a script tonight to curl several URLs, but sleep for 2 minutes in between each request. I piggybacked on a little script written by programmer John McCann from NYC. Here's what the code looks like:
#!/usr/bin/env ruby
RAILS_ROOT = File.expand_path(File.dirname(__FILE__) + '/..')
require File.join(RAILS_ROOT, "config/environment")
puts "writing curl script..."
t1 = Time.now
foos = Foo.find_by_sql("select distinct bar from foos;")
curls = foos.map! {|foo| "curl 'https://some.api.com?data=%7Bfoobar%3A#{foo.bar}%7D&key=12345'\n"}
curl_script = curls.join("sleep 120\n")
File.open("curl.sh", "w") {|f| f <<>
t2 = Time.now
puts "curl script written in " + (t2 - t1).to_s + " seconds"
What's fun about this script is that it was a new challenge for me on a couple fronts. I learned about encoding curl requests (%7Bfoobar%3A#{foo.bar}%7D produces {foobar:[value_of_foo.bar]}). After clumsily grabbing all objects and filtering after the query, I refactored the SQL to just grab distinct values from the db. I learned that the "w" attribute of the File.open class method either creates a file or sets its byte count to 0 if it already exists. And finally I learned about the "sleep" function which takes an integer parameter representing the number of seconds to wait until the next line is executed - this was especially helpful in not hammering the service I was accessing.
So not a major script, but pretty fun and interesting nonetheless.
In Conclusion,
I heart curl.
Behavior-driven development (BDD) is a programming paradigm that emphasizes defining behavioral characteristics of your code before actually writing any code. An example is if I'm defining a calculator controller my calculator should return 2 when given the equation 1 + 1, should return an error when trying to do division by 0, etc. By clearly defining what your code should do before writing it, it makes it much easier to write solid, test-covered code upfront and makes it a cinch to debug as you go along because you're immediately alerted whenever new functionality accidentally breaks legacy portions of your codebase.
I've found BDD much more intuitive than TDD (test-driven development). The above video by Dave Astels, one of the original developers of rSpec, gives a nice overview of BDD vs. TDD and the pros of the former. Also touches on the benefits of using a dynamic language like Ruby.
In Conclusion,
Pretty neat...
Designed By :
