Alex Hopmann’s Blog

Today I check the app I’ve been building and I get a spew of dozens of errors-

CSS Error (line 0 char 113): Expected end of value for property.  Error in parsing value for property.  Declaration dropped.
CSS Error (line 0 char 114): Expected end of value for property.  Error in parsing value for property.  Declaration dropped.
CSS Error (line 0 char 114): Expected end of value for property.  Error in parsing value for property.  Declaration dropped.
CSS Error (line 0 char 114): Expected end of value for property.  Error in parsing value for property.  Declaration dropped.

I’m pretty sure its the way I’m setting the margin property which is valid CSS, but might not be the precise syntax they are expecting-
<div style=”margin: 10px 20px 0px 20px;”>

This goes back to the point that they can change the platform and how they parse FBML at any time and without warning break you. I wish they provided a “staging” server. The idea is that you can develop your app there, test it there, and any platform changes they do get rolled out at the staging server for at least a week before the move them to production (except of course for any fixes to exploits). This at least would give developers a fighting change of staying on top of this stuff.

The other big issue this brings up is the perception of the cause of the problem. I’ll give the Facebook folks some credit for using fairly neutral language in their text, but the implication is still that the problem is with the app developer. TechCrunch just ran a piece on Facebook apps and how many of them are failing to scale. Of course, the catch is that while many of these apps might be done by some non-professional folks on a shared hosting server that can’t handle the load, that is not necessarily the real story.

My app is running on a dedicated machine in a datacenter. The machine is a fairly high performance dual-core machine that is typically running at less than 5% usage. My uptime as recorded by various tools has been 99.86% for the past 8 months (with pretty much 99.99% for the past 3-4 months). I can hit my site directly and I never get a failed request. Yet when accessing my Facebook apps on the same machine I see the same error messages that TechCrunch is attributing to poorly designed unscalable apps.

There are lots of possible explinations. It could be a bug in the code of my app where it hangs somehow. Unlikely, but its possible. It could be a complex interaction in Facebook calling my server and then my server making callbacks to Facebook to server the request. But in any case something is turning out to be less than commercial-quality reliability and it doesn’t feel like its in my control.

Makes you think twice about exposing your brand to these kind of issues. I’m planning on following up with some other developers I know to see if they are encountering the same sort of things.

I’m continuing to use Launch21’s blog as a place to put posts that are more directly about writing code. Since I’ve been working with the Facebook platform late at night the past week I’m working on a set of posts on working with the Facebook APIs. They are all pretty new so there aren’t many resources yet on the Internet to help out so check it out if you are interested. My latest post is about FBML vs. IFrames for Facebook applications.

I’ve been playing with building apps for Facebook the last few days. Mostly it is going pretty well, but there are a couple of little issues I’ve been struggling with. I’ve noticed via email and comments that some of my posts about technical problems I’ve faced and solutions have been the most popular, so I’m going to try to keep up a good flow of these.

Their documentation doesn’t really have step-by-step explanations of what happens over the wire yet. I think all the details are there somewhere, but it took reading the PHP sources to fix some issue with the app I was building in .NET. The big issue is that the example sources showed doing a redirect when a user is first connecting to your app and hasn’t authenticated yet. However if the user is accessing you in the “canvas” (IE- inside Facebook), a normal HTTP redirect is NOT the right thing to do. Instead you need to return the FBML for a redirect-

Response.Write(”<fb:redirect url=’http://www.facebook.com/login.php?api_key=” + AppAPIKey + @”&v=1.0′/>”);

Another issue I hit is that it feels like I really need two accounts to test my application and its interaction with other users. I have not gotten notifications to work yet. The catch with this is there is a checkbox that hides your application from people other than yourself while you are developing it (’developer mode’). But while that checkbox is checked, my second account can’t access the app. So this is a bit of a catch-22.

The other thing I’ve noticed is that Facebook won’t let me be signed in from more than one computer at a time. I typically am using 2-4 computers at once and really appreciate that most of the Google sites, GTalk, and others let me be signed in all over and they just work. Its a real pain when testing stuff that whenever I use a different computer to access Facebook it makes me sign in again.

One of the most useful unix commands is tail and its been too bad that this isn’t built into Windows. In linux you can type “tail -f filename” and it will monitor a text file and display in realtime new stuff that gets added to the end. This can be very useful for debugging servers by letting you monitor log file output.

I’ve discovered two versions of this for Windows. One “Tail for Win32″ can be found at http://tailforwin32.sourceforge.net/ . This one uses a GUI app to let you open multiple files, configure filters and watch the results. Its not a command-line utility so its not really in the spirit of the unix one, but the funcionality works great.

The other one is in the Windows Server 2003 resource kit . Once you install it, you should have the “tail” command-line utility available.

Rahul has a good write up about the Facebook developer garage last night. First of all I’d like to thank the hosts- both the local Seattle guys and the Facebook team that flew up for the event. They sent a bunch of people which is a pretty big statement about how seriously they are taking this platform stuff.

A couple of my own observations about the recent Facebook stuff, especially in relation to their platform aspirations-

The big draw here is that Facebook is becoming the magic way that you sprinkle “viral” on anything. Up to now just about every startup I have worked with has spent lots of time trying to figure out how to build some viral mechanisms into their products. No one wants to go spend millions on saturation advertising campaigns (not that those necessarily work so well anymore anyway) so the premise of building some cool small feature and having exponential userbase growth to millions of users in just a week or two sounds great.

Of course building those features and managing the community and social aspects of pulling it off can be very hard (ok, building the feature is easy, its the other part that is hard). By use Facebook’s existing community and viral mechanisms, in theory it should be much easier to latch into their 33M and growing userbase with your app. You still need to build a compelling app and think through why people want to share it, but probably half the work is already done for you (including some of the hard part).

At the same time, Facebook does have a few problems to deal with. First of all the definition of “compelling app” has been a bit loose initially. There are a number of very simple apps that have had great success getting millions of users to sign up with them in a short time, but its hard to see how those are going to stand the test of time and generate any meaningful revenue. On the other hand iLike is probably the definition right now of what it means to be a compelling app, bringing a bunch of rich information to the picture and tapping into some deep needs that are especially social.

Peyman pointed out to me that one of the big things they are missing is revenue share. My initial reply was that with 2000 developers signing up in 2-3 months, who needs to bother with revenue share? The size of the potential audience is large enough that people will gladly build apps without getting revenue directly from Facebook.

But what this is missing is the issue of alignment of interests. Right now listening to some of the people building Facebook apps, it sounds like most of them are just trying to grab Facebook users and channel them into their own things. There was lots of frustration with Facebook limiting amount of notification, but its pretty clear to me why they do that- right now people would spam the heck out of the users if they could. In any case, a rev-share scheme would align developer’s interests with those of Facebook. It worked pretty well for Google AdSense, and although it is not directly the same thing, they could make this work for them.

Early on the host asked who was working on this stuff for their day job. It was striking to me that almost no one raised their hands. Maybe those who are working on this full-time either didn’t have time to show up for this event or were just keeping their hands down. This is not to slight the potential of some of those nights and weekend projects to hit it big, but it also shows how early all this stuff is.

Finally it feels like Facebook is dealing with some real identity / culture issues. They grew up as a college oriented network, but unlike MySpace have focused on keeping things clean and less obnoxious. Yet, many of the developers there said that the audience seems like mostly high-school students, and many of the apps are cutesy in a way that is likely to turn off audiences older than 25. They have a real opportunity right now to catch a broader audience of the country, but at the same time there is a big danger of a backlash if the older audience doesn’t feel like spending time on Facebook means being overrun by high-school kids and content that is tuned for them.

I’ve got some posts about experiences with Silverlight over on Launch21.com.

Dare posts about a friend writing about the origins of LINQ and its history with ObjectSpaces. I also worked with the ObjectSpaces team as they went through several iterations forced by various political winds inside Microsoft. We were hoping that they were going to be a great compliment to databinding in Avalon (WPF). Ideally you could easily define some database schemas, create some .NET objects to represent your data logic, and then use WPF databinding to create great user interface on top of it. All resulting in an application with great abstractions so you can evolve the various parts independently as necessary.

I had done some similar experimentation back in 1999-2001 (using Java to model an object programming layer first for Exchange and later for SQL). From my perspective the key was to not try to do a full complex “object relational” layer where you make things artificially automatic. Don’t hide the underlying database, but make it a lot easier to interact with it.

So far the most effective version of this is pretty much the ActiveRecord library that is part of Ruby on Rails. Judy’s Book also has their own version for the various sites built there, and I’ve built my own as part of various Fast Carrot / Launch21 projects. Writing lots of custom SQL and dealing with generic records all over your UI logic can be a big pain, and you also get stuck with poor choices for where to put your business logic. Part of what makes these technologies contraversial is that the database purists want you to put all the logic in the database. You build stored procedures, triggers, or more recently .NET based custom types that live in the database. The advatantage of that approach is that you have a guarantee of consistent behavior no matter what client talks to your database. For certain OS or enterprise applications this is very important. For most of the web-applications we build on the other hand this is a non-issue and just makes building the whole thing a giant pain.

I haven’t had a chance to get my hands dirty with LINQ yet but I’m hopeful that its going to be really cool. I know there were a bunch of neat projects brewing in this space so if they make the database side of the programming really interface with .NET in an elegant way, that could be a huge win for .NET programming.

I’ve been posting over on the Launch21 blog about the CouponLooker vertical-search engine that I’ve been doing for Judy’s Book. Interesting stuff- this is one of the more fun projects I’ve done in a while. I suppose I should be embarrassed to admit that I did about zero research into how search is supposed to be done. Still, the results seem pretty good and its fun to share some of the techniques that I’ve developed so far.

On another front I’m interested in tracking the evolution of hard-drive prices. Here are the current top price/performance figures for 3.5″ drives-

400GB = $97 = $.243/GB
500GB = $119 = $.238/GB
750GB = $240 = $.32/GB
1000GB= $413 = $.31/GB

500GB is still the sweet-spot. The 1TB drives aren’t really available yet so the 750GB drives are still priced at the “highest capacity available” premium. I’d expect once the 1TB drives become easily available the 750GB drives should drop quite a bit quickly.

The Silverlight announcements at MIX this week are pretty exciting. I’d been doing a bunch of work in WPF/E (the old name for Silverlight) and the new release seems like some solid progress.

One of the most interesting parts of the announcement is the support for a mini-CLR that runs .NET code anywhere Silverlight runs. It appears to have a very limited set of the framework libraries. Given that the install is only 4MB this isn’t a surprise. But my big question is how will interop work between the .NET and Javascript work.

One of the bigger problems we had with Avalon (WPF) meeting the needs of web developers is that we changed the app model all around. You weren’t serving dynamic script from the server, the app had to be compiled and use web-services or something to talk back to the server. WPF/E was interesting because you could use some of the same graphic capabilities while sticking with a conventional Javascript coding model.

If Silverlight supports good Javascript / .NET interop you could have the best of both worlds. Build controls, etc, in .NET where the cleaner programming model and better performance helps. And script the logic and flow of your app in Javascript using conventional web tools. I haven’t had a chance to dig into the new release but it looks promising.

I’ve also got my fingers crossed for an announcement of linux support. I can think of about 5 or 6 projects that could use Silverlight if there were support for running on linux.