It’s simple. Go to Account->Account Settings->Account Security->Secure Browsing and click a checkbox.

Option for using https "whenever possible"

After saving, your Facebook experience will all flow over SSL, every byte encrypted with a 128-bit key. But fire up your favorite game, and you will probably see a request to turn this setting off.

Dialog displayed by apps that don't support SSL

If you click the continue button, you might expect that you’d be temporarily allowing an unencrypted connection. Instead, your setting is turned off. When you’re done with CityVille, you will have to switch it back on again. I’m sure Facebook will improve this user experience over time.

When Facebook rolled out this feature, they added a new setting for app developers that asks for the URL to the secure version of their app. It starts out blank, and when it is blank, the dialog above shows up. Naturally, I wanted to get things right, so I began experimenting. Unfortunately, once you have a valid value, you can’t return to having it be blank. Now I was forced to solve this somehow.

Time for a short diversion into how HTTPS works.

You know how you can have one server hosting multiple domains, each with their own site content? It’s called virtual hosting, and it’s a standard feature of Apache. The way it works in the HTTP protocol is that when your browser connects to the server, it uses the IP address (e.g.192.168.1.1) and in addition to asking for the document to view (e.g. GET /index.html) it also specifies the domain name (e.g. www.18int.com). Apache’s configuration knows where the files on the server are for that domain, and away we go.

In the case of a secure connection, your browser and Apache must exchange keys to be used for encrypting data. Your browser will also ask for proof of identity from the server. The proof is in a small file called a certificate. It’s only good for one IP address and one domain. You can make multiple certificates work if you have multiple IPs. A certificate signed by an authority is a few hundred dollars, but IPs are scarce. It’s a gigantic pain in the neck for a small developer.

If you have multiple apps running on Facebook, you could reorganize them on the server to use subdirectories instead of subdomains. For both canvas apps and iframe apps, the user is hardly exposed to your backend URLs anyway. In the short term, I’ve made a single page that says the following.

We’re sorry! This app does not function when requested via ssl. To access this app, please change your facebook settings under Account->Account Settings->Account Security->Secure Browsing.

Then I pointed all of my SSL URLs at it. Note that I this page is served up using a self-signed certificate. It’s interested that Facebook doesn’t care to enforce the identity check but they do care that the data is send via SSL end to end. That’s reasonable.

Instead of reorganizing all of my files on the backend, I plan to rebuild my apps so that they work outside of the Facebook canvas, using the Facebook Connect feature instead. Facebook seems to be doing what they can to push everyone off of the canvas, anyway.

It’s also interesting that most of the games I’ve tried still show the request to switch off SSL. The popular Zynga games do. I found that Golden Nugget Vegas Casino, run by one of my clients (AltEgo), does serve up with SSL. Smart.

Recently, Twitter added a similar feature to always use HTTPS, but I wouldn’t expect any issues like we have with Facebook because Twitter never got into the business of piping content from apps through their own servers.

Screenshot of using the @mentions feature

Do you use the @mentions feature in your status updates? If you type @ and immediately start typing a name, Facebook will suggest friends. Click on one and the name is inserted as a link. The friend will be notified and more likely to notice. Until now, this only worked in your own status updates. It now works in comments on anything posted to a news stream.

Unfortunately, the @mentions feature does not work when updating status via the Graph API. Apparently it did at first, but app makers immediately used it to spam everyone with notices. Facebook yanked it. I would have preferred that they limited notifications similarly to how they limit how many news stream updates can go out in a certain time period.

In addition to mentioning people, you can also mention pages and apps.  Many of the things you “like” in your profile have underlying pages. If you’re mentioning a band or a movie you enjoy, try using the @mentions feature to make it easy for readers to find out more.

Related articles

• Facebook Expands @ Mention Tagging to Comments (insidefacebook.com)
• Facebook Adds Ability to Easily Tag Others In Comments (mashable.com)

You’ve worked for months on a Web application, you launch and all is fine. Now you need to add a new feature that will take you at least a few hours to get right. Do you subject your users to the errors that will intermittently appear if you code directly on the site? No, of course not. You make a completely separate installation that only you’re looking at. When the feature seems solid, push the changes to the production version. You are using a source code repository, aren’t you? So, just perform a svn update on the live site and you’re all good.

This diagram shows the relationship between development, staging and production servers.

Following is the method I’ve found works best for smallish teams working on LAMP Web apps where you can’t afford to introduce bugs to the production version. This method has worked for me on teams of 5-10 coders, each working on different features at once. There’s a balance to be struck between not getting in the way of development work and getting updates out promptly. It’s a drag when you can’t release one feature because its code is all mixed in with another, half-finished feature.

The main idea to have one checkout for your production version, one for a staging and testing version, and multiple servers for various developers and/or projects. Changes that are ready to be tested are checked into the repository. When you want to release, you freeze checkins and test the staging server. When you’re convinced it’s all good, you run an update on the live server and allow checkins again. You’ll want at least three different databases, one each for live, staging and development.

For relatively short-term work, developers should usually check in frequently. For long-term projects, checkins should be held back. Yes, this is what branches are for, and that’s the right choice for more senior coders. In practice, branches don’t seem to be something that the junior members can grok. I might have junior developers working on big changes to copy over many weeks. I simply rely on backups to make sure they don’t lose work in case of disaster.

Here’s a set of steps I might take to set up a new development system.

1. Create a subversion repository.
2. Create three virtual hosts: www, stage, and dev.
3. Create three databases.
4. Checkout the app once each for www and stage. You’d view these sites as www.example.com and stage.example.com.
5. Make an open directory for the dev subdomain and make a checkout for each developer. You’d view these sites as dev.example.com/coder1/htdocs. Allow all the dev versions to share a database.
6. Protect the dev server from the public with basic authentication. You don’t want Web robots indexing everything, and you don’t want to expose scripts that would be outside of the apache webroot in production.

This system will allow you to quickly make a new checkout without hassling with making new subdomains and tweaking the apache config.

FreeTime is a Web application written in PHP for MySQL that allows you to keep track of projects. It tracks comments, files and timesheet entries for projects divided up by clients and their divisions. Recently added features, not appearing in previous versions, include tasks, estimates and more reports. There’s also code that allows clients to log in to review work as if it’s a mini-site, but it hasn’t been tested in production. The most well-developed aspects of the application are related to timesheets, both gathering them from staff and then reporting on them.

I’m curious whether anyone will find the code useful, whether for educational or practical purposes. Its purpose was as a highly customized solution for Clear Ink, and it may have no utility outside the same type of consultancy. On the other hand, it could prove useful after some hacking. I would use it for myself if I do more consulting again.

You can download the source code from the FreeTime project page on SourceForge.

Now that I’m about 80 pages into the book, I thought I’d grab a copy of the PDF version for easy reference whichever desk I’m sitting at.  The print edition comes with a “free” ebook. There are two ways to get this free ebook.

The way they want you to do it is as follows.

1. Cut open a folded paper in the front of the book.
2. Go to the URL printed on the paper.
3. Type in a code they ask you for out of 9×20 grid.
4. Type in another code from the grid.
5. Type in your name and email address.
6. Wait for the email to arrive.
7. Find the email in your spam folder.
8. Click on a link to start the download.
9. Rename the file from “gi” (wtf?) to something rational, such as “Zend_Framework_In_Action.pdf”.

However, you could do the following.

1. Enter “zend framework in action pdf” into Google Search.
2. Click to some blog.
3. Click the link into RapidShare.
4. Wait for your 30 seconds to expire since you are a “free” user.
5. Download the .rar file.
6. Expand whatever’s in the rar file. (I didn’t actually go this far).

Typing in codes from a grid is pretty annoying. I threw down $45 to get the book. Maybe they should just trust me and print a direct download link inside the text of the book. After all, we’re all only a couple of links away from downloading it from RapidShare. What would have been really cool was if I could have downloaded the PDF for free first and then bought the print version when I decided that the book was of great value. I had that exact experience with another author recently.

If you are going to buy Zend Framework in Action (and you aren’t in a rush like I was), you might use the Amazon.com link above. It’s a lot cheaper than buying it off the shelf at B&N.

It’s somewhat obtuse to get the apps on your own profile. Visit the app’s profile page (linked above). Click the button to add the app. Then, modify your profile and add the “module”. (I’m hand-waving a bit here). I think you must be upgraded to the 2.0 version of profiles.

Despite my bickering about how I was fighting with the approval process last month, I did get the advice generator active. The band names app was approved within hours. So maybe they like to hassle unproven developers. In any event, the advice generator has been live for less than a month and has 116 “active users”. I’m not clear if that means installs, or if people have activated the module in their profile. I can’t find any examples of profiles with it installed.

I had an app done in August but got distracted for several months. Over the Christmas break, I found the time to polish it up and release it. The main feature of the app is a personal database of migraine events with the aim to helping you discover patterns or triggers. In the context of Facebook allows you to automatically let your friends know you’ve had a migraine. That could lead to better understanding or just a feeling of comfort.

You can get started using the app by visiting the Migraines About Page on Facebook.

One advantage in waiting was the the new template bundles for the news feed is working flawlessly. In August it was brand new and buggy. I also had more fun with the Google Chart API. Once you get a few migraines recorded, I can generate a pie chart of how severe they are and a line graph of how many you have each month.

We wanted to take a moment and thank you for all of your great work and amazing applications that have helped make Facebook Platform the largest and fastest-growing social platform over the past year and a half. As we end 2008 there are over 660,000 of you worldwide building applications that give users more powerful ways to share and connect, and collectively your applications have reached nearly 140 million people.

It’s a stark contrast to the total lack of developer love shown by MySpace. I hope Santa leaves some coal in their stockings. I have no doubt there will be many presents under the trees of the Facebook Platform Team.

I am so very pleased to be working with Facebook in their mission to bringing people closer together. Little notes like this remind me of Mark Zuckerberg’s presentation last July and how I came away feeling inspired. So, to Facebook, I’d like to say, “no, thank you!”

Facebook set a standard for the developer experience. It works as follows. I join the developer group; I’m a developer. I don’t wait to be approved. I self-identify and I get started. I can immediately build a demo app. I can place it in a sandbox mode where only people I’ve designated can view it, or I can just make it live. Once I think it’s polished, I can submit it to Facebook’s directory. That will get me some free advertising. Or I could skip it. I could drive traffic to it with ads. It doesn’t matter. Facebook offers me the freedom.

Facebooks offers a system for certification that shows off my app as complying with their ideals for apps. I have to pay for this, and for most apps, it’s probably not worth it. I like that Facebook is trying this and letting the market decide. I suspect consumers won’t care about the certification, but I still appreciate them experimenting and letting developers opt in.

MySpace takes a big brother approach to developers. You apply to get an account, and you wait. I’m not sure what they actual check about people, perhaps that their email isn’t fake. Once you get into the developer program, you must create a “profile” for each application you develop. That requires a unique email address, even for a demo app. This must have been someone’s bright idea to overload the meaning of profiles at MySpace instead of generating unique IDs…except, apps do have unique numeric IDs. Facebook got this right–create an app, get a long, unique ID. Plus, on Facebook, I am shown as the developer. I don’t have some other email address that MySpace sends junk to.

On MySpace, I can see my app, but no one else can until it’s approved. This isn’t actually clear, since as you visit the live versions of your profile or home page, you see your app. If you recommend the app to a friend, no error is generated. I only understood this after I looked over a friend’s shoulder to see that my app did not appear for him when he looked at my profile.

So, I clicked to publish my app, and I waited two days. I was irritated to find it rejected. I got boilerplate complaints that I had to decipher how they related to my app. And I got this warning at the end of the email: DO NOT REPLY TO THIS EMAIL. THIS MAILBOX IS NOT MONITORED. (Yes, it was all in caps like that).

Some of the issues were valid, and it was good to get the feedback. I hadn’t tested the app on MSIE, and some quirks in the Javascript prevented it from working on that browser. Other issues are bogus and prevent me from providing the experience that is best for the users.

I want to allow my users to install the app either on their profile, for their friends to see, or on their home page, for their eyes only. It’s a reasonable decision. MySpace keeps telling me  “must contain unique content on every application surface“. I’ve actually seen other apps behave this way, so I can only assume that whatever mindless approval mechanism is in place (human or otherwise) is just happening to catch me. Perhaps other developers have figured out that you develop your app once for approval and then again for being useful. I have to finally get approved before I can test that idea.

I’m on my third round of asking for approval. I’ve made 5 minutes of changes today and now I can wait another 24 hours to see if I get satisfaction. One of the latest bit of feedback, which was new to the latest round but had been there from the beginning, is related to targets for links. If you link off of myspace.com, then you must set your link to target a new window. I see why you have to do this–the app is in an iframe and it loads the remote site in the little frame otherwise. MySpace hosts the application code. Why don’t they just add targets to links themselves? Facebook touches every bit of code to make it work best with their site.

I can only conclude that MySpace does not think of developers as providing value for their site. Facebook clearly understand the fair exchange of values. Developers make these sites more attractive to users. The more time spent on Facebook, the more ad revenue for Facebook.  MySpace seems to take the attitude that developers are miscreatants who must be forced to follow the rules. Facebook has a laisse-faire attitude. Developers try ideas in the market and Facebook only intervenes in cases where the apps are clearly being harmful.

It’s an interesting balance. Certainly MySpace tends to allow it’s users run rampant. They still allow users to place big chunks of CSS code in their “about me” profile box. Facebook attempts to keep the user experience uniform. You don’t get to have a black background on your profile page. It’s clear that Facebook spends time on serious user experience development. MySpace continues to appear to be an ugly hack.

Update 12/19: Of course, the next day I get a brand new complaint from MySpace. Today, it’s “Canvas Surface of the app is not appropriately sized to fit the module.” When I get these complaints, they include a link to Application Guidelines. That previous complaint about unique content quoted these guidelines, but this time I can’t find the word size anywhere on the page! Maybe that guideline was revised away the last time they updated the guidelines November 19th. I think I’ll just turn off the canvas page completely like I did the home page.

Update 12/22: I guess the reviewers take weekends off. Of course, the app was rejected yet again. Last Friday I used the checkbox on the developer console labeled “Enabled”. I unchecked it. I didn’t bother to click to where the “canvas surface” used to be because I logically assumed that with it disabled, there’d by no point. Applying logic to this process is clearly a mistake. The rejection I this time complained about an invalid canvas surface. It’s invalid to uncheck the checkbox?!? Why is it there?!? OK, so, the canvas is turned back on with just some plain text explaining that although I don’t want anything to be here, I have to put something there. I have to admit, I’m just about done screwing around with them. I feel like I’m talking to a random error generator.

Update 12/26: I guess putting some text for the reviewer on the canvas page works because I got a reply that makes it seem like it’s in reply to my complaint. Still, the app was rejected. This time it’s because I used the word “MySpace”, which implies affiliation with MySpace. Right. I did did get some advice for how to disable the canvas: redirect the user to the profile. I think the advice was meant to be about gadgets.views.requestNavigateTo(), although the advice mentioned navigateTo, which I think is a method on the window object in MSIE. I decided to be nice and tell the user that they are about to be sent to their profile page by including a 3 second timeout with a link to go their immediately. I wonder what error the MDP folks will complain about next.

Update 12/29: I’m finally approved. Now that I am, I can see that any change I want to make must go through the approval process again, even just a small text change. I have to think that however they are reviewing apps, it can’t scale up if they ever match Facebook which has more than 660K developers. It also strikes me that rapidly adapting the app to user behavior will be dampened if you have to wait a day for every change to be approved.

One of the most enjoyable parts of LinuxWorld for me is the spectacle of JJ asking booth people really hard questions. The atrophying conference meant there were fewer people to put on the spot, although we did give the NYT guy and the mobius strip gal some trouble. When we passed the foot massaging shoe booth, I realized what this was–spam! My conference has been spammed! Yuck!

After the conference, I had the pleasure of chaperoning Dmitri Gaskin, Drupal wunderkind, to the PHP Meetup at the CNET building. Dmitri is 12 years old and the son of Igor Gasowski, with whom I’ve worked at Clear Ink for the past five years. JJ and I both had a lot of fun sitting in Starbucks and advising Dmitri on various computer science topics. There was a time when JJ was fresh out of college and I had a few things to teach him. I now find it hard to understand him half of the time. Fortunately, I can still understand the things Dmitri tells me, although when he first explained CCK to me a few months ago, it took me a bit.

One thing JJ and I agree on is that young programmers should read Hackers by Steven Levy. Programming techniques are one thing, but it’s harder to acquire an understanding for history and lore of the craft.

Dmitri and I had dinner with Lee Springer at Chevy’s and then headed over the CNET building for the PHP Meetup. Joe Stump talked about a new system in PEAR for hosting your own repository channels. It’s obvious how this can help keep code straight, especially for a company like Digg that has many production servers. PEAR’s system for installing modules is similar to Apt or RPM. Having been coding in PHP for so long (11 years!), my tendency is to do things the “old way”. So, while I’ve taken sips of the PEAR koolade, I’ve never taken a big gulp. I’m still trying to sort out PEAR versus Zend Framework versus sticking with my FreeEnergy codebase.