Skip to content
February 13, 2011

Notes from the week of 2011-02-13

PayPal X Platform:

Big data:

Big data growth from Teradata

Wireless and mobility (never would have thought Nokia would pick Microsoft):

APIs and web development:

Personal things:

Running:

February 12, 2011

Web API power tools: Steps to RESTful programming bliss

I’ve been using a lot of RESTful web APIs of late.

I’m writing about them for the PayPal X DevZone blog (see my recent MoSoLo posts) and testing and documenting them in other work.  I’ve also been doing some RSS feed data harvesting and filtering which, although it’s not technically RESTful work, uses a lot of the same skills and technologies to get things done.

If you’re doing any web development these days, I suspect you’re elbow deep in RESTlike and RESTful stuff, too.

Which leads me to this question:  What tools make your RESTful development more fun and efficient?  I have a few favorites I’d like to share.

My general approach when encountering a new API is:

  1. Learn about the resources available through the API (time to read the documentation, source, and example code)
  2. Prototype API calls, using an API console where possible; this can often be done in parallel with step 1 to speed things up
  3. Once I have reasonably sorted out calls, I copy them into my scripts and programs and test to make sure everything’s good-to-go

Example:  I recently wrote about the Facebook Graph API.

Read the complete post on the PayPal X Developer Network to learn how I got up to speed using Facebook resources, an Apigee console, and good old command line cURL.

Apigee Facebook console

February 6, 2011

A very busy December and January

It’s been a very busy two months since my last monthly highlight post, so it’s about time to catch up.

For starters I published four articles, on four different technical topics, in the DevZone in the last couple of months.

First up was “Streamlining Purchases with Mobile Express Checkout” which discussed the new Mobile Express Checkout (MEC) technology, differences between MEC and other PayPal mobile techologies, and when to use the various options including MEC.  The article provided a refresher on plain old Express Checkout (EC) before diving into the details required to enable a mobile EC.  If you want to mobile-enable your customers, you need to know the material in this article.

MEC payment flow

My next article discussed using the Apigee PayPal API console to assist in your development of Adaptive Payments applications.  It provided an overview of what the console is and what you can do with it.  I’d suggest everyone working on PayPal programming and QA at least skim this article so that they know about the capabilities.  Also note that Apigee offers many consoles beyond just the PayPal one; this is discussed in a bit more detail in the article, too.

My third article during this period detailed “Developing and Deploying PayPal Apps“.  PayPal Apps are software gadgets served by PayPal to customers’ web browsers.  They enable you to provide access to your payment applications from an Apps tray on the PayPal.com site, potentially significantly increasing the visibility of and traffic to your application.  Apps are built upon a subset of the OpenSocial gadget framework which allows you (and PayPal) to leverage a lot of third party work and tools from the likes of Google and Apache.  One of the most refreshing things about Apps is that it is so incredibly simple to get started; with some ingenuity and a little bit of XML you can be up and running in very little time.  I highly recommend this article if you are looking for ways to grow your application’s exposure to more PayPal users.

Bill's example PayPal App ready to run in the sandbox

My most recent article, “Divining DevZone Insight from Filtered Feeds and Deep Pages – Part 1, The Harvest“, is the first part of a two part series exploring tools and techniques to harvest and analyze data.  It focuses specifically upon DevZone content, but the principles and methods can certainly be generalized to other situations where you have RSS feeds and HTML pages full of data you’d like to analyze in an updatable, ongoing manner.  In this article I discuss the content of interest, outline my plan for conducting the harvest, and try a couple of tools out including Yahoo Pipes and YQL.  Watch for the second part of this series coming soon.

Click here to read the rest of the article on the PayPal X Developer Network including a look at recent blog posts and important related news from around the Web.

February 6, 2011

Notes from the week of 2011-02-06

Using YQL within a Yahoo Pipe

My PayPal X DevZone writing:

Big data (this week, a focal point was the first ever O’Reilly Media “Strata” conference):

Wireless and mobility:

APIs (lots of information on Yahoo Query Language aka YQL):

Web development and site stuff:

Personal things (the Blizzard of 2011):

February 4, 2011

The Facebook APIs, part 4: Getting the good stuff via the Graph API

This is my final installment in a four part series on Facebook’s MoSoLo related APIs and technologies.  You can read the previous three posts here:  Part 1 provided a brief history of the Facebook Platform, part 2 introduced social plugins including the ever present Like button, and part 3 delved into how to use Facebook’s implementation of the Open Graph protocol to enable your content for Facebook’s users.

I’ve saved the best part of the Facebook Platform for last:  The Graph API.  As Facebook describes it:

The Graph API presents a simple, consistent view of the Facebook social graph, uniformly representing objects in the graph (e.g., people, photos, events, and pages) and the connections between them (e.g., friend relationships, shared content, and photo tags).

You interact with the Graph API by requesting information on the current state of the object(s) of interest in the graph.  Like all good One True Web Path RESTful web APIs, Graph API requests result in JSON server responses that are manipulable in client-side JavaScript or your own language or tool of choice.

To access the public properties of an object in the graph, you make a secure HTTP request to graph.facebook.com with a path of /ID where ‘ID‘ is the unique ID of the object of interest within the Facebook social graph.

For instance, to request the public properties of the object representing my Facebook account, you would make this call:

https://graph.facebook.com/753868366

To see the graph in action, click the above link.  You should receive the following JSON server response:

{
   "id": "753868366",
   "name": "Bill Day",
   "first_name": "Bill",
   "last_name": "Day",
   "link": "http://www.facebook.com/billdaycom",
   "gender": "male",
   "locale": "en_US"
}

Note that for people and pages with Facebook usernames, you can use a username in place of an ID in graph API calls.  So you can alternatively request the properties of my account by making the call shown in the first part of this series, https://graph.facebook.com/billdaycom, which will return the same JSON object as above.

The Facebook Platform developer site has a username of ‘platform’, so you can request information on it within the graph via:

https://graph.facebook.com/platform

which returns:

{
   "id": "19292868552",
   "name": "Facebook Platform",
   "picture": "http://profile.ak.fbcdn.net/hprofile-ak-snc4/hs451.snc4/50414_19292868552_7650_s.jpg",
   "link": "http://www.facebook.com/platform",
   "category": "Product/service",
   "website": "http://developers.facebook.com",
   "username": "platform",
   "founded": "May 2007",
   "company_overview": "Facebook Platform enables anyone to build social applications on Facebook and the web.",
   "mission": "To make the web more open and social.",
   "likes": 1379443
}

All objects in the graph may have a picture that represents them.  For a person, this picture is their profile photo, but other things such as events, pages, applications, and photo albums all have such a picture, too.  To render that picture, you send a request of the format /ID/picture; for example, my current picture (profile photo) is available via:

https://graph.facebook.com/billdaycom/picture

which renders as:

https://i0.wp.com/profile.ak.fbcdn.net/hprofile-ak-snc4/hs720.ash1/161662_753868366_6949286_q.jpg

You can also request the picture in other sizes, for example get the large size via:

http://graph.facebook.com/billdaycom/picture?type=large

which renders:

https://i0.wp.com/profile.ak.fbcdn.net/hprofile-ak-snc4/hs720.ash1/161658_753868366_3475681_n.jpg

The Graph API would be minimally useful if these were the only sorts of operations it provided.  It starts getting really interesting when you learn how to ask the system for more information than you initially have.

Click here to read about the Graph API’s search and introspection capabilities detailed in the complete article on the PayPal X Developer Network.

February 2, 2011

Watch Strata keynotes live

Strata conference keynotes are being livecast. Watch the latest below.  [UPDATE:  Now that the conference has ended, O’Reilly is providing recordings of the keynotes via the stream embedded below.]

You can also follow along via Twitter with O’Reilly Media’s @strataconf and hashtag #StrataConf.

Watch live streaming video from oreillyconfs at livestream.com
February 1, 2011

Divining DevZone Insight from Filtered Feeds and Deep Pages – Part 1, The Harvest

I’ve been contributing to the PayPal X Developer Network for a little over six months now, and it’s been a lot of fun. I love exploring the PayPal X Platform with you, and in particular focusing on the parts of the platform you find intriguing and most useful.

Near the end of last year, I started wondering which specific topics you were most interested in. How was our DevZone content doing with Developer Network community members? What were the topics you as a group were saying you most wanted to read about? And of those topics, which ones were members actually reading, i.e. what was getting the hits?

I decided to do some analysis of my own blog posts and articles. I collected hit statistics for my 2010 content and sorted it by date, hits, and hits broken out by type (article or blog post). I used that data to write up a summary of my findings. I also surveyed readers on their preferred application development language(s) (click here for the results) and which third party APIs matter the most to them. I am using all of this data to work out what to write for the DevZone in the coming months. One major area of focus that’s clearly emerged: Mobile + social + local APIs, technology, and application development which I’m now collectively referring to and tagging as “MoSoLo“.

As I worked through my own content from 2010, I also started thinking about how I might generalize my analysis to include all of the DevZone content from every contributor. How would I collect the data? What could be automated? And most importantly, what insight could be gained from the exercise?

This article is the result of my investigations into gathering up the pertinent DevZone content. A follow-on article will explore the data to summarize each logical topic and highlight what was learned from the analysis.

What shall we harvest?

I wanted to analyze all of the DevZone blog posts, articles, and book excerpts from the “Blog” and “Documents” RSS feeds. If for some reason those feeds wouldn’t provide me with everything I needed, I decided I would then mine the HTML page versions, in effect the “deep” pages, linked to from the DevZone Blog and Documents pages.

I gathered together a list of all of the content locations. In addition to the DevZone links, I also included blog links for each of the four regular DevZone contributors (Matthew Russell, Travis Robertson, Ethan Winograd, and myself). These individual blog links contain posts made by each of us before the new, all-in-one DevZone feeds were created.

Here then is a table of the HTML pages for each of the six areas to be harvested as well as their RSS feed links.

Source content homepage Feed location Number of items as of 26 January 2010
DevZone blog posts RSS 171 posts
DevZone articles and book excerpts RSS 63 articles and excerpts
Matthew Russell’s blog posts RSS 13 posts from before the cutover to the common DevZone blog feed
Travis Robertson’s posts RSS 11 posts pre-cutover
Ethan Winograd’s posts RSS 3 posts pre-cutover
My posts RSS 14 posts pre-cutover
TOTAL: 275 items

Note that connections to the Developer Network server, and thus to both the pages and the feeds, are secured via HTTPS. This will be important later.

The plan

After gathering links to the content, the next thing I needed to do was figure out how to collect the data together into an analyzable form.

My first inclination was to sort out a mechanism that would allow me to plug in the RSS feeds for all six content sources, pull down all the items from each, sort them by their publication date, and then access and manipulate the resulting stream for analysis. I would pick the most promising tool I could find and then see if it could be used to successfully access and analyze the data. I had very limited time to sort out an automated mechanism, so if my top choice or two didn’t work out straight away, I would fall back to a spreadsheet as my backup plan. Falling back was not desirable from an efficiency and automation standpoint, but I knew it would work if everything else came up short.

My search turned up several dead-ends and then a couple of promising automation possibilities. My plan of attack became:

  1. Use Yahoo Pipes to combine the six RSS feeds into one and then operate on their contents as needed.
  2. If Pipes wasn’t able to handle the task by itself, try using Yahoo! Query Language (YQL).
  3. If Pipes and YQL failed, manually enter data from the article, book excerpt, and blog post pages for each item into a Google Docs spreadsheet for sorting and analysis (this is the same procedure I’d used previously for my own content).

Want to learn how to implement this? Read the full article on the PayPal X Developer Network (click here).

Sneak peak of the implementation discussed in the full article on the PayPal X Developer Network

January 30, 2011

The Facebook APIs, part 3: Plug content into Facebook via Open Graph

This post is the third installment in my ongoing series on Facebook’s mobile, social, and local APIs.  You can read the first and second installments here:  Part 1 introduced the Facebook Platform and part 2 focused on Facebook’s social plugins.

This time we’re discussing the Open Graph protocol.  Open Graph enables you to use HTML meta elements and the Facebook Like button to integrate your pages into the social graph.  Facebook describes the user experience thusly:

Including Open Graph tags on your Web page, makes your page equivalent to a Facebook Page. This means when a user clicks a Like button on your page, a connection is made between your page and the user. Your page will appear in the “Likes and Interests” section of the user’s profile, and you have the ability to publish updates to the user. Your page will show up in same places that Facebook pages show up around the site (e.g. search), and you can target ads to people who like your content.

Facebook's illustration of how Open Graph plugs your content in FB

Click here to read the complete PayPal X Developer Network post on how to plug your content in Facebook via Open Graph.

January 30, 2011

Notes from the week of 2011-01-30

My PayPal X DevZone writing:

Wireless and mobility:

Big data:

Web development and site stuff:

Personal things:

Running:

Example PayPal App ready to launch

January 26, 2011

Developing and Deploying PayPal Apps

How would you like to be able to get more traffic for your PayPal-based applications? Embed your apps in the PayPal.com site? Have thousands or even millions of customers consider and potentially use your new application?

If that sounds like a great opportunity to you, you need to look closely at PayPal Apps. PayPal Apps allows you to develop a lightweight, web standards based “gadget” that will embed your application functionality into PayPal’s site on a new PayPal Apps tray, making it available to the masses of PayPal account owners.

Intrigued? Good! Let’s dive into the details so you can start developing and deploying a PayPal App of your own.

What is PayPal Apps?

First, a bit of terminology. “PayPal Apps” does not refer to a native smartphone or tablet application (sorry iOS and Android), nor to a client-side Windows or Mac or Linux application. Neither is it a reference to PayPal-based applications in general. It refers very specifically to a HTML, CSS, and JavaScript based software “gadget”, packaged via an XML-based module referred to as the “gadget specification” or “gadget spec”, and served by the PayPal Gadget Server to a customer’s web browser. This gadget runs within the web browser and is rendered in an HTML iframe. Besides communicating back to the PayPal Gadget Server, a PayPal App may only communicate from the browser to one other domain in the network cloud; this domain is specified during App submission and the service running there is referred to as the “service endpoint”.

PayPal Apps are built by developers, tested in the PayPal Sandbox, and submitted to PayPal for review and approval. If approved, they are made available via a PayPal Apps tray on the live PayPal.com site. From there, they will be visible to millions of PayPal customers. Build the right App, and you could see tremendous traffic in short order!

You can read more about what PayPal Apps are and aren’t, as well as things to note as you begin Apps development, via the excellent “Developing a PayPal App” technical overview page.

As I wrote in a recent DevZone blog post, PayPal Apps were launched at Innovate 2010 to much fanfare. There was a good introductory session given on Apps, “PayPal Apps: The Future Starts Here“, and it is worth watching to familiarize yourself with the technology and its use:

You should also read through PayPal Technology Evangelist Rasesh Shah‘s series of blog posts on PayPal Apps. The first installment does a good job of defining Apps and how to get started with them. Read any or all of his four installments by clicking on each of them here: “Getting Started With PayPal Apps“, “Building Your First Hello World PayPal App“, “Making payments from a PayPal App (Gadget)“, and “Building an advanced PayPal App“. And remember his “HelloWorld” example in particular, as we’ll refer to it again later.

If you cut PayPal Apps, it bleeds OpenSocial

OpenSocial logo

If you decide to try your hand at PayPal Apps development, you will want to dig a little deeper under the covers. PayPal wisely chose to build Apps on top of the OpenSocial gadget framework. OpenSocial originally spun out of the Google Gadgets framework as an attempt to guarantee an open alternative to the proprietary Facebook Platform for social application development. By embracing this open model, PayPal has guaranteed maximum transferability of skills and availability of tools with minimum overhead. Very smart.

OpenSocial supports both general purpose (non-social) gadget-based development as well as building and deploying social networking types of applications. For more information on the OpenSocial technologies, please refer to the OpenSocial Foundation’s web site and especially to the OpenSocial specifications page, JavaScript API reference, and Articles & Tutorials (strangely enough titled “My Life”).

Read the full article on the PayPal X Developer Network to learn the details about what is included from OpenSocial in the PayPal Apps framework, the Apps security model and implementation, how to build and deploy a HelloWorld App, and where to turn for more information if you encounter issues. Click here to read the article now.

« Older Entries
Newer Entries »
Design a site like this with WordPress.com
Get started