Posts tagged API

Selected (belated, extended) Saturday Links

The past two weeks haven’t really left time to compile my selected links, though there have been many. A few days at SxSWi (on which more, later) followed by travelling with the family and the inevitable work backlog moved blogging way down the priority list. So here’s a mammoth selection to get me caught up. Particularly interesting has been the discussion around the future of newspapers (represented here by Clay Shirky, Steven Johnson and Russell Davies), which seem to have finally pushed beyond “how t ind a good business model for papers” to looking at where the real value for society lies and how we can preserve and extend that in a changing landscape.

Ecampaigning Forum: Notes on Open Space sessions

Gathered feedbackWhile my live blogging efforts focussed on the more formal sessions at ecampaigning forum, most of the event’s time and content was spent in groups following the Open Space methodology. The gatherings for people to suggest sessions were instructive in themselves as they gave considerable hints as to the key concerns of ecampaigning practitioners.

How to engage with the big social networking sites, whether to create your own, organising around big events (such as G8 summits and climate conferences) and ways of managing decentralised/coalition campaigns were some of the big themes, but the sessions covered a wide range beyond that such as engaging with young supporters, or older supporters, choosing content management systems, operating on a tight budget, pooling resources/tools and one hastily agreed discussion of twitter. What follows are a few notes on things that struck me.

The twitter session drew a mixture of existing users, aware onlookers, and newcomers. A lot of time was spent exploring existing uses of the site with examples such as teamtibet’s usage to co-ordinate protests around the olympic flame and Downing Street’s account. Most people seemed taken with its potential for short term co-ordination, but many questions arose about its potential for long term campaigning beyond informing core supporters of news updates. Being seemingly the longest-serving twitter user there, it was interesting to hear responses to a tool I’ve quickly come to take for granted

A recurring theme was the adoption of drupal by a number of the big agencies. Most seem keen to contribute code back to the community, along the lines of AI and CivicActionsassets module. I’ve mentioned my mixed feelings about drupal before but am hopeful that through events like this we might be able to resolve some of the issues that frustrate me.

I brought up Russell Davies’ 2008 – the year of peak advertising in conversation over breakfast on the first day and that phrase recurred a few times. There’s a general awareness that the last few years have brought lots of opportunities to attract attention by simply being quick to adopt some new “web 2.0″ tool, but that won’t last. It didn’t seem like there was a sustained discussion or much sense of where to go next, but working hard to attain attention has been the life of campaigners for a long time and so perhaps this is just another step in that journey?

There’s clearly a growing sense of how hard it is to influence big summits where the final communique is often planned months in advance. Gatherings of world leaders are a great opportunity for media coverage and to present the “actionable moments” that Ben Brandzel spoke of, but they’re now when the real chance for change occur. It’s vital to find ways to turn the energy around these summits into sustained, directed action after the final communique is published, planning the next steps before the events themselves take place.

In the session on pooling resources and tools a number of questions came up about the ethics of collaborating with big players like google (who have just been on a big outreach programme for their new Google Earth offering for NGOs). The data provided and the tools offered by the likes of Google can be a great boon to charities operating on tight budgets, but at the expense of ceding a lot of control and a lot of attention data (and with providers like facebook there are concerns about things like this). It was obvious that there is some desire to develop open source tools that provide similar tools, but it’s not clear whether the resources are there. Mention was made of open street map and I brought up the theyworkforyou api, and it definitely would have been interesting to have had people who could present on the usage of that; some concerns remain as to how ready those tools are for non-geeky end-users, which would be easy to resolve if someone were to direct the right resources.

I’m looking forward to seeing what other people bring up in their notes on the event, and what themes come out in the ongoing discussion. You can see my photos on flickr, find some content on technorati and check out the conference wiki for more. All my posts on the topic are gathered under the ecf08 tag.

The MySpace platform: now official

The rumours of MySpace launching a platform or API have been floating for quite some time, but now as reported on the O’Reilly Radar they have been confirmed.

Over the next two months they are going to increase third-party access to their site. First, they are going to highlight the thousands of widgets that have been on their site for years now. This should be released in the next couple of weeks. I am assuming that it will go beyond the FIM’s Spring Widget Gallery. Second, they are going to offer an API for applications to all developers. However, these applications are going to be sandboxed initially and 1-2 million users will have access to them. If the users deem the applications safe and useful they’ll be available to all users. Developers will be able to advertise in their applications.

It’ll be interesting to see whether the MySpace platform and API are truly a step towards openness or whether it’ll be another walled garden a la facebook. Facebook’s platform is phenomenally successful, but doesn’t really open up their core data (status, events, etc.) for developers to interact with. Given their track record it’s unlikely that MySpace are really going to launch something more open that that.

For developers, and for the musicians whose presence is MySpace’s key calling card, this is a tiny step but not one that makes easier the services that we really need. Musicians still need to update their information across dozens of walled gardens rather than having easy tools to use. Developers still need to scrape and hack if they want to provide a way to access core parts of users’ profile, and unless MySpace address the many, many technical problems on their site (unreliability, apparently random use of captchas, awful HTML) that’s going to remain a huge hassle.

Of course, the key question will be whether this announcement will help MySpace retain their pre-eminent position. The crown has slipped over the last few months, with facebook’s popularity rocketing and people deleting MySpace contacts and accounts in order to focus on just one social network. I suspect MySpace will never get their crown back. If they do, it’ll have to be because they’ve radically changed the social networking game.

Avoiding MySpace (or, cross-posting with WWW::Mechanize)

It seems that anyone involved in helping musicians with their web presence has to learn to tolerate MySpace. I don’t think I know anyone who actually enjoys the process of using MySpace, but a strong presence there is a must have for almost every musician these days.

I’ve long wished for a decent API that would help me integrate MySpace with websites I run for musicians—after all, it isn’t very DRY to post the same content in several places when it could be automated—but as time has gone on it’s become clear that an API would be entirely anathema to MySpace’s approach to the web.

So while working on some updates to a friend’s website I decided to try out the Ruby port of WWW::Mechanize to automate the process of posting blog entries over at MySpace.

Firstly, we need to be able to log in. To do that, you can almost copy some of the library’s examples as it’s as simple as:

agent = WWW::Mechanize.new
agent.user_agent_alias = 'Mac Safari'
 
page = agent.get('http://www.myspace.com')
login_form = page.forms.with.name('theForm').first
login_form.email = username
login_form.password = password
logged_in = agent.submit(login_form)

Posting a blog entry is a little trickier, as MySpace uses javascript to change forms’ ‘action’ attributes based on which button you click, and occasionally inserts tokens in the URLs, but after a little exploration I came up with:

blog_page = agent.get('http://blog.myspace.com/index.cfm?fuseaction=blog.create&editor=false')
blog_form = blog_page.forms.with.name('theForm').first
 
# Here we have to grab the action as it includes a token which can change
new_action = blog_page.body.match(/document.theForm.action = '(.+?)'/)
blog_form.action = new_action[1]
 
blog_form.subject = subject
blog_form.BlogCategoryID = category
blog_form.body = body
 
now = DateTime.now
blog_form.postMonth = now.month
blog_form.postDay = now.mday
blog_form.postYear = now.year
blog_form.postHour = now.strftime('%I')
blog_form.postMinute = now.min
blog_form.postTimeMarker = now.strftime('%p')
 
submitted = agent.submit(blog_form)
 
confirm_form = submitted.forms.with.name('theForm').first
confirm_form.action = 'http://blog.myspace.com/index.cfm?fuseaction=blog.processCreate'
posted = agent.submit(confirm_form)

And that’s all there is to it. I’m impressed with how easy WWW::Mechanize makes interacting with forms, and generally how pleasant it is to work with. Performance is pretty good too, specially given how problem prone MySpace is. It’s nice to be able to imagine a scenario in which clients can cross-post their content to MySpace. If we’re lucky, we never need actually visit that website again!

I’m working on packaging up the code, probably with support for posting event dates and ‘bulletins’, and adding in error handling to deal with the 75% of the time (based on my usage this afternoon) when MySpace returns an error page. It may be a few days, but I’ll post a note here when it’s ready.

Services_Technorati version 2

In an effort to tidy up various older projects that were never quite completed, I’ve turned my attention to my first PEAR module Services_Technorati. It’s a very simple wrapper around the Technorati API, but the PHP4 version never reached a stable release as it depended on some other packages which were also never stabilised.

So it seemed time to make the simple step of converting the code to be PHP5-only and use simplexml for their XML parsing. That removes the dependencies which were slowing me down, and should result in improved speed along the way as the XML parsing is now handled in C rather than PHP. I just released 2.0.0alpha1, but the code should be pretty stable and I’m hoping to run through the steps and get a stable release out very soon.

Update (27th Feb): I’ve just pulled this release and re-released it as 0.7.0. Apparently because the package never release 1.0 in its original version, I should just continue with the previous version numbers despite the change to PHP5.