Pressly Makes Sense

Hey Jeff and Peter,

I just finished watching the videos of you launching Pressly at TechCrunch Disrupt. Well done. You and your team should be really proud of what you’ve achieved.

I wish you’d been given more opportunity to elaborate on your strategy to win. Instead you had to spend most of the Q&A time defending Pressly’s raison d’etre to Dustin Moskovitz et. al. That was unfortunate; deck stacked against you. But you did a nice job staying the high road and giving solid answers to the skeptical questions.

Jeff, I loved your comment about publishers being great at telling stories, and not so great at building technology innovations to deliver those stories (in compelling new ways, with compelling profitability). It’s true. And it’s good, I think, that Pressly is joining a cadre of other players in this same space. Existence of multiple players is proof that the market is ready. And publishers need lots of options right now, especially ones that let them do fast, cheap experiments. Pressly can help them do that.

I suppose controversy-seekers could frame this as “walled garden versus open web, round 2″. That was my very first thought after watching the video. But that isn’t really the case, is it? Neither the iPad/App Store ecosystem nor HTML is going away anytime soon. There will be multiple winners in this market, with multiple technology bets. Consumers will buy many different kinds of devices, and consume content in many different places and ways. It’s probably more accurate to compare Pressly’s space to the blogging services market back when it was just getting going: Blogger, WordPress, Movable Type, and so on. Lots of experimentation and diversity, with consolidation down the road.

My biggest takeaway on all this is that Pressly makes a lot of sense from a publisher’s point of view. Publishers are losing sleep over how to follow their audiences to digital devices without abandoning all the assets they hold dear: their brand, destination websites, exclusive content, and UX. And with limited capital and time/runway remaining for technology investment (or investment of any kind) they have to be brutally frugal and thoughtful about what bets they make. Pressly has good answers on the economics (very little cash up front), the technology (more open), the user experience (niiice), and control issues. Clearly The Economist and Toronto Star think so, and I bet many others will reach the same conclusion.

I hope Pressly does really well.

Let me know when I can buy some shares.

osh

How to query for count of Facebook Likes and Shares on a specific URL

If you have a site hosting the Facebook Like button you may at times want to query Facebook for the number of Likes displayed within the button. Here’s how.

I couldn’t find a way to do it with Facebook’s Graph API, but there’s good support for it in the FQL API. You can craft up queries by hand, as shown below, and issue them right from your web browser. The response is an XML document with the statistics for the URLs you want to know about. There are also FQL wrapper libraries in several languages… for Ruby I had some success with the fb_graph gem.

Multiple URLs example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url in(“http://bing.com”, “http://google.com”, “http://facebook.com”, “http://twitter.com”)

Single URL example:

https://api.facebook.com/method/fql.query?query=select  url,like_count, total_count, share_count, click_count from link_stat where url = “http://bing.com”

Within the XML results, the “total_count” attribute is the number shown within the Facebook Like widget.

Docs:
http://developers.facebook.com/docs/reference/fql/link_stat/
http://developers.facebook.com/docs/reference/fql/

Heroku, MongoHQ, and Amazon S3 Backups

I spent a few hours yesterday convincing MongoHQ to back up a Mongo database to an Amazon S3 bucket via an Amazon “IAM” account. Here’s the secret recipe. Hopefully it saves someone time.

Context: MongoHQ, which I’m using with one of my work projects right now, is a service that hosts MongoDB databases. It integrates with Heroku, allowing you to get started on a Heroku app using MongoDB very quickly. MongoHQ supports hourly and daily backup of their databases to Amazon S3 buckets, but alas, not yet for databases provisioned automatically via Heroku. So if you want to step up to a backed-up database you’ll have to set up your own. Here are the steps I followed to do it.

Secret decoder ring:
S3 = Amazon Web Services Management Console, S3 tab.
IAM = Amazon Web Services Management Console, IAM tab.
MHQ = Mongo HQ console.
HKU = Heroku.

Recipe:

  1. S3 : Create a bucket for your app’s backups, e.g. “my-app-backups”.
  2. IAM: Create an IAM User account for MongoHQ to use, e.g. “mongohq”. Download the credentials and store them safely.
  3. IAM: Create an IAM Group to contain all users with backup permission, e.g. “myapp-backup-writers”.
  4. IAM: Add the mongohq User account to the newly created Group.
  5. IAM: Using the Permissions tab of the Group’s properties attach a new security policy, granting permission to write to the myapp-backups bucket. See below for a sample policy.
  6. MHQ: Sign up for your own MongoHQ account.
  7. MHQ: Create the database you wish to use with Heroku.
  8. MHQ: Select the “Backups” tab and enter the IAM User credentials from step 2.
  9. MHQ: Click “Save Settings”. If all is well you’ll see a message, “Setting Updated”.*
  10. MHQ: Create a new user on the Database Users tab.
  11. MHQ: Copy down the Mongo URI string from the Database Info tab, substituting your user name and password from step 10.
  12. HKU: In the root directory of your Heroku app do “heroku config:add MONGOHQ_URL=’URI’”. URI is the Mongo URI from step 11. (Normally Heroku sets this variable for you when it provisions a MongoHQ database. You’re overriding it with a link to your own database.)

* Step 9 is where I got stuck. It worked fine with my own personal security credentials, but not with the IAM account I created specifically for MongoHQ to use. (I wanted more security… giving your main account credentials to a 3rd party site isn’t smart.) I fiddled around with the security policy for quite a while, and eventually discovered I needed the “ListAllMyBuckets” permission. Here’s the security policy that worked for me:

    {
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [ "s3:ListAllMyBuckets" ],
          "Resource": "arn:aws:s3:::*"
        },
        {
          "Effect": "Allow",
          "Action": [
            "s3:PutObject",
            "s3:PutObjectAcl"
          ],
          "Resource": [
            "arn:aws:s3:::MY-APP-BACKUPS/*"
          ]
        }
      ]
    }