Purplepixie Software and Dave's Blog

Monthly Archives: November 2015

Hmm so I wrote this in November 2014… and didn’t publish it. Then found it again in November 2015. I don’t know why it was in draft – usually because there’s something horribly wrong with it. But… seems ok, and I haven’t played with the FB API since then so I doubt I can add anything (or even that it still applies) hence… PRESSING PUBLISH:

I blame lack of sleep and time pressure but actually this was a pain in the behind. However I have two tips for future sufferers:

1. Development Domain

Facebook will only accept requests from domains you have linked. In our case this means our live domain. We develop locally on our machines (127.0.0.1 or localhost) but you can’t register those as valid domains.

However what you can do is create an A record in your domain to 127.0.0.1 so you now have local.yourdomain.com pointing to 127.0.0.1. You can add local.yourdomain.com to facebooks’ domains for your app and off you go.

2. URL is required at both ends

The docs say you must pass a request_uri to redirect to when calling – but you must also pass the SAME uri on return or else death and room results.

This means that your two files (http://domain.com/sender.php and http://domain.com/recipient.php) must have code like:

When a web client needs to periodically refresh data held on the server there are generally two approaches. Interval polling (“short polling”), which is most commonly used, where the client repeatedly re- connects to the server for updates, and a technique in which the HTTP connection is kept open (“long polling”). Although work exists investi- gating the possibilities of long polling few if any experiments have been performed using an Apache MySQL PHP (AMP) stack. To determine the potential effectiveness of long polling with this architecture an ex- periment was designed and conducted to compare update response times using both methods with a variety of polling intervals. Results clearly show a marked improvement in timings with long polling, with the mean response time down to 0.38s compared to a mean of just under the polling interval for short polling. Issues of the complexity and load implications of wide use of long polling are discussed but were outside the remit of this experiment owing to a lack of resources.

Notes

Note that this is a just basically a subset of work performed as part of work performed for my MSc dissertation.

Last year we undertook the challenge to design, build/develop and deploy our business cotravel in 54 hours. This culminated in a working system (with proper back end, usable APIs, web interface etc), several actual business agreements with local taxi companies, and finally an excellent presentation by Rod.

During the two days of (frantic) development we used a git repo on BitBucket to manage our source code between the development machines, test, and live environments. This got me thinking it would be nice to visualise the development process mining the repository, if only I had the tools and computing power. Then I remembered I totally do! Analysing software systems, including from repository logs, is kinda what we do. So, waiting for a long experiment to finish, I realised I could quickly bodge a couple of our tools together and see what I could get.

During the development period (evening of 20th November to evening of 22nd November) there were two developers: David (me), and Adam (not me). So I plotted commits by hour both per developer and in total, from the very first commit at 17:28 on the 20th to the last at 16:46 on the 22nd.

And there we have it, from 0:00 on the 20th to 23:59 on the 22nd. As you can see the main splurge of work (technical term) was on the 21st from 06:00 to 22:00, which is when we built the majority of the functionality. On the 22nd we again got an early start, but nowhere near the commit intensity and it petered off anyway, after go live at 14:00 on the 22nd to the presentations.

Two interesting peaks on the 21st – the first was mainly Adam putting together the agreed UI elements and repeatedly pushing it up for all to see. The second peak was me trying (and generally failing) to master the Facebook API, as it needed domains working etc and so had to be pushed to a live server to test (until I found a workaround which I really should document).

Of course once we went live…

We then had all manner of other stats available to us, for example a log of visitors to the site and the number of API calls made from our snazzy web 2.0 front-end to my dodgy interfaces. We went live at 14:00 and kept track every hour until 20:00.

Here’s the graph showing (in 1000’s) the page views and (much higher) volume of API calls made to the system from 1400-2000 when we finally collapsed.

Overall Sync the City was a great experience, a lot of fun and a great way to meet interesting people and do ninja coding (plenty of opportunities to DevOps the **** out of it, or as we used to call it; make live changes to the code while users are still interacting).