Tag Archives: php

Running tinytinyRSS on Cloud Foundry

Google Reader is going away in a week or so, and my friends have been asking me where I’m migrating all of my feed reading activities to. The answer for me is a combination of Flipboard and Feedly (both of which I recommend), but for those who prefer a more traditional Reader-style UI and also to retain ownership of their data, running tinytinyRSS is a possible alternative. I’d heard about it, but was tipped off to it again by my friend Dave Neary over at Red Hat 🙂

tinytinyRSS is a PHP application and needs a MySQL or PostgreSQL database. It offers the ability to import an OPML file (basically an XML format for listing RSS subscriptions), as well as various other capabilities and plugins.

Since we launched Cloud Foundry Hosted Developer Edition (aka CF v2) last week, I thought I’d find out how much effort it would be to install and run ttRSS on our new platform. It should “just work” – with buildpack support, you can now bring your own runtime to the platform… and we currently have free Marketplace SQL offerings from ElephantSQL and clearDB. Checks all the boxes!

Here’s what happened when I set up ttRSS on run.pivotal.io (the new URL where Cloud Foundry Hosted Developer Edition from Pivotal runs, replacing the old cloudfoundry.com beta hosted service).

First, I read the installation guide and downloaded the latest release tarball (linked at the bottom of the main wiki page). Then I unpacked the tarball on my Mac.

Once inside the release directory, I decided to just “push” the app to Cloud Foundry. I knew I’d need a PHP runtime, so my first thought was to point at the Heroku PHP buildpack (CF v2 is compatible with many Heroku buildpacks). I grabbed the URL and entered the following:

Tiny-Tiny-RSS-1.8  cf push --buildpack=https://github.com/heroku/heroku-buildpack-php
Name> tinytiny

Instances> 1

1: 64M
2: 128M
3: 256M
Memory Limit> 256M

Creating tinytiny... OK

1: tinytiny
2: none
Subdomain> tinytiny

1: cfapps.io
2: mqttbridge.com
3: none
Domain> 1

Creating route tinytiny.cfapps.io... OK
Binding tinytiny.cfapps.io to tinytiny... OK

Create services for application?> y

1: blazemeter n/a, via blazemeter
2: cleardb n/a, via cleardb
3: cloudamqp n/a, via cloudamqp
4: elephantsql n/a, via elephantsql
5: mongolab n/a, via mongolab
6: rediscloud n/a, via garantiadata
7: treasuredata n/a, via treasuredata
What kind?> 4

Name?> elephantsql-53b67

1: turtle: Tiny Turtle
Which plan?> 1

Creating service elephantsql-53b67... OK
Binding elephantsql-53b67 to tinytiny... OK
Create another service?> n

Bind other services to application?> n

Save configuration?> y

Saving to manifest.yml... OK
Uploading tinytiny... OK
Starting tinytiny... OK
-----> Downloaded app package (3.1M)
Initialized empty Git repository in /tmp/buildpacks/heroku-buildpack-php/.git/
Installing heroku-buildpack-php.
-----> Bundling Apache version 2.2.22
-----> Bundling PHP version 5.3.10
-----> Uploading staged droplet (12M)
-----> Uploaded droplet
Checking tinytiny...
Staging in progress...
Staging in progress...
  0/1 instances: 1 starting
  1/1 instances: 1 running
OK

Hurrah! The app is deployed! Note that while I was running through the steps here, I also chose to provision an ElephantSQL instance and bind it to my app. I could also have done that via the Marketplace in the Web Console before pushing the app. The tinytinyRSS wiki suggested that it performs better with Postgres than it does with MySQL, so I chose to use that.

The next step in the regular installation is to visit the URL (in this case http://tinytiny.cfapps.io) and check that things are working OK. When I got there, I found a form asking me to fill in the database credentials.

That’s a small issue – right now, there is no autoconfiguration for PHP apps with databases on Cloud Foundry, and I hadn’t modified the application code to grab the information from anywhere in the environment. Fortunately, there is a way to find out what the settings should be – via the env.log file in the application container. Running cf logs got me back the contents of the file. VCAP_SERVICES is where I needed to look.

VCAP_SERVICES={"elephantsql-n/a":[{"name":"elephantsql-53b67","label":"elephantsql-n/a","plan":"turtle","credentials":{"uri":"postgres://xxxxkjkj:lbI7r3Bh@babar.elephantsql.com:5432/xxxxkjkj"}}]}

I’ve modified the values here, for obvious reasons, but I plugged the values from the elephantsql service right into the form… hit the Test DB button… and got an error that my PHP runtime didn’t have support for mbstring…

Hmm!

Fortunately, there’s another buildpack for Heroku which adds PHP support, and does have support for mbstring (as well as using nginx instead of Apache, and a few other tweaks). I thought I’d give that one a go instead. I’d already saved my application settings to the manifest.yml file, so I could not just push a second time with a different buildpack, I had to use the --reset flag to apply the change:

Tiny-Tiny-RSS-1.8  cf push --buildpack=https://github.com/iphoting/heroku-buildpack-php-tyler.git --reset
Using manifest file manifest.yml

Uploading tinytiny... OK
Changes:
  buildpack: 'https://github.com/heroku/heroku-buildpack-php' -> 'https://github.com/iphoting/heroku-buildpack-php-tyler.git'
Updating tinytiny... OK
Stopping tinytiny... OKStarting tinytiny... OK
-----> Downloaded app package (3.1M)
-----> Downloaded app buildpack cache (4.0K)
Initialized empty Git repository in /tmp/buildpacks/heroku-buildpack-php-tyler.git/.git/
Installing heroku-buildpack-php-tyler.git.
-----> Fetching Manifest
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/manifest.md5sum
-----> Installing Nginx
       Bundling Nginx v1.4.1
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/nginx-1.4.1-heroku.tar.gz
-----> Installing libmcrypt
       Bundling libmcrypt v2.5.8
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/libmcrypt-2.5.8.tar.gz
-----> Installing libmemcached
       Bundling libmemcached v1.0.7
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/libmemcached-1.0.7.tar.gz
-----> Installing PHP
       Bundling PHP v5.4.12
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/php-5.4.12-with-fpm-heroku.tar.gz
-----> Installing newrelic
       Bundling newrelic daemon v2.9.5.78
       https://s3.amazonaws.com/heroku-buildpack-php-tyler/newrelic-2.9.5.78-heroku.tar.gz
-----> Copying config files
-----> Installing boot script
-----> Done with compile
-----> Uploading staged droplet (38M)
-----> Uploaded droplet
Checking tinytiny...
Staging in progress...
Staging in progress...
Staging in progress...
  0/1 instances: 1 starting
  0/1 instances: 1 starting
  0/1 instances: 1 starting
  1/1 instances: 1 running
OK

Success again! reloading the configuration page, I was greeted with confirmation that the database connection was now working.

Screenshot_21_06_2013_14_58-4

After this, I simply needed to initialise the database, save the configuration, login, change my password, and import my Google Reader OPML file (there are ttRSS plugins which also allow you to import your whole Google Takeout from Reader, including likes and shares).

Screenshot_21_06_2013_15_16-2

As I said, I’m personally a big fan of Feedly and I don’t think I’ll be using ttRSS full-time, but this was a really nice and very quick way to prove that Cloud Foundry v2 is ready to host these kind of apps – even with the redeployment step to swap buildpacks. You might want to give it a try!

 

Community, telephony, and prototypes: Make-a-thon

Warning: long post! the first in a series covering some of the events I’ve attended or been involved with lately.

Background

At January’s London Internet of Things meetup, I had the privilege to hear Haiyan Zhang speak with passion about various topics, including how she had collaborated with hackspaces in Japan in the aftermath of last year’s earthquake and subsequent nuclear disaster.

It was only the first time I’d come across Haiyan, so I was surprised but delighted that she invited me to the OpenIDEO Make-a-thon this past weekend, after tweeting about events like the London Green Hackathon.

I had only a vague idea what to expect of the Make-a-thon. When I saw some of the project briefs being published ahead of the day, I knew that it would be a little different to hackathons and other tech events I’d been to in the past. The briefs spanned issues such as improving local communities, bike safety, and several supporting campaigns by Amnesty International to use technology to support human rights activities.

My initial impression that it would not be a “run of the mill” tech event was reinforced when I arrived at the IDEO offices in Clerkenwell on Friday afternoon – it was a very different crowd to the ones I typically encounter – full of product designers, makers, human factors specialists, as well as web coders and developers. I rocked up with a bunch of Nanodes and other electronics with a vague thought of doing something hardware-related, but in the event I didn’t get that far!

IDEO’s typical approach to design revolves around prototyping and directed brainstorming, and in the event we divided into 8 teams of around 6 each, with diverse skills but with common interests around the briefs on offer. Friday afternoon was spent first understanding and exploring the brief, and then rapidly prototyping a rough idea before presenting it to the rest of the group. Saturday was spent refining the idea and producing an “experience prototype” which was intended to have been tried out “in the real world” if possible.

Evolution of the “Karma Phone”

Several of the briefs interested me, but I joined the team focused on the concept of Postcode Gangs – how could we build something to develop and improve community facilities within a postcode – essentially an arbitrarily-delineated area – in London? We spent some time brainstorming ideas around what “makes” a community before needing to rapidly decide on something to build for our rough prototype.

IDEO Makeathon

“What if” – there was a ringing phone in the middle of the street – and on the end of that phone, someone who knew something, had something to offer, or who was needed something? “What if” – we could create a new local hub with current and historical information about an area, enabling people to explore and meet their neighbours?

So the first prototype of what came to be called Karma Phone involved a lamppost (named, erm, Dan!) with a phone on it, which would randomly ring as people passed by – people could call it with a need and that others could then try to address. On the other side of the lamppost (also known as, Dan’s back) we imagined a large touch display with information about current events, realtime information, historical maps, and so on.

Karma Phone – The Outcome…

The team changed overnight, as Hayley and James were not able to stay for Saturday, Lydia joined us, and Victoria could only be involved for a short time on Saturday. We weren’t all convinced that a ringing phone would be answered, that the system wouldn’t be abused, that there wasn’t a social barrier around providing home address and asking for help, etc. How could we get an actual phone into the street and ringing, too? So, Saturday morning involved some rapid rethinking of what we wanted to build!

We settled on what turned out to be a subtle evolution of the original idea – a public phone which could act as a hyperlocal information service and skills exchange.

While we were brainstorming how to hack a physical phone, run a long cable into the street, use a mobile chained to a metal box, etc etc I remembered Twilio, which I’d been following for a long time, but never had the chance to hack on in anger. Within about 30 minutes I’d demonstrated the ability to initiate calls between two users from a web page, to the rest of the team.

Karma

Steve and Dan set about implementing the web UI; Tim started working on a physical enclosure; Victoria and Lydia managed to source a real “traditional” phone handset; and I remained hard at work writing PHP to talk to Twilio.

A couple of minor wrinkles along the way:

  • network issues meant that I had to use Tim’s phone to tunnel through to my webserver’s console, since it was apparently impossible via the event wifi. Evidently IDEO had just had a network provider change, so it was just an awkward time, but I lost some time fiddling with hosting in the early part of Saturday.
  • at a certain point on Saturday afternoon, I realised that attempting to call from the Twilio web client on the iPad was never going to work… since it requires Flash. I thought of a number of workarounds, but the one that finally stuck was that we were able to use Skype on the iPad, and use the skype:// URI scheme to launch the app from the web client. It wasn’t seamless as we needed Skype credit, and also had to tap an extra “call” button in order to start the call, but it was good enough for a prototype.
  • I’d wanted to make the web app, a standalone launchable web app on iOS. Weirdly, adding the usual meta tags to the page header to instruct iOS to treat the app as standalone launchable, meant that it was no longer possible to invoke Skype from within the web UI… so I backed off from that idea. The only cosmetic issue that presented was an inability to hide Safari “furniture” like the header, but that wasn’t a big problem for a prototype.

Here’s how the final system hangs together:

KarmaPhone-overview.png

Impressive Outcomes…

I spent so long coding and tweaking on Saturday (the commented and documented code is here – ignore how short it might seem – it was an intense few of hours!) that I missed most of the physical assembly. Tim and Dan did an amazing job of creating an enclosure for the iPad and handset. It might have been made from foam board, a box folder, and vinyl, but the final result was beautiful. And most importantly – it was fully functional!

IMG_5753

We would have loved to get the prototype out on the street for public testing (I suspect none of us more than Steve and Lydia!), but time worked against us. The final experience prototype was presented as a live demo with willing audience volunteers – one example call going to an answering service, and the other redirected to the local expert on Scotch Eggs (Tim!).

I’m happy to say that Karma Phone won Best Digital Prototype at the event, and I was (apparently!) Best Tweeter. Nice accolades 🙂

So – conclusions? I really enjoyed the way we worked together as a team of very unique and different talents; and seeing the Karma Phone prototype realised so brilliantly. However, I also think the experience of the Make-a-thon was humbling… listening to the experiences of people illegally detained abroad, and seeing some truly brilliant ideas from all 7 of the other teams, was wonderful.

A huge thank you to everyone involved in the first IDEO Make-a-thon – a really unique hackday. The IDEO team in particular looked after us brilliantly, with superb facilities, a great welcome, and more-than-adequate quantities of the hacker staples (coffee, sweets, pizza and beer).

Read a full recap including information on all of the project briefs on the OpenIDEO site. There’s a gigantic set of photos from the IDEO team, and a much smaller one from me shot on an iPhone at lower quality.

Tim, Dan, Hayley, Victoria, Steve, James, Lydia – Thank You. It was a pleasure!

All of the other teams – you rocked. You did great things. I salute you!

Experiments with PHP and MQTT

Over the past few days I’ve been playing around with combining lightweight messaging and PHP. There are a couple of reasons for this, but the primary one is that I’d like to extend my prototype iPhone CurrentCost monitoring web application to display more up-to-date information about the state of my home energy usage. I’d planned to do this for a while, but recently Mark Taylor created his own version of the iPhone interface (PDF link) and he has got current readings on the front page. Clearly, I have to compete 🙂

Actually, in my system, I’d like to do things a different way. The heart of my setup is a Really Small Message Broker. At the moment, data from the CurrentCost meter comes in over the USB connection and is then published in pieces, or on topics, to the RSMB (temperature and energy readings are separate). These published messages are then read by a script which is subscribing to the topics and squirrelling the historical data into an rrdtool database; and also being pushed up to our IBM broker “in the interweb cloud” via an MQTT broker bridge connection.

So in theory, having the up-to-date information in the web UI should be a simple case of grabbing the MQTT publications on each topic and displaying them. The way I’ve coded things (and would prefer to do things), this involves having the ability to subscribe to MQTT publications from PHP.

I’m not at the end of the road yet, but I do have a starting point.

howitworks.png

I’ve got a front-end test page which currently uses Prototype to send an Ajax request to a server-side PHP script (yes, I have had jQuery recommended to me, and I may well look into that instead of Prototype, but this works).

The server-side script uses the Simple Asynchronous Messaging PHP library. SAM is a wrapper which enables a variety of messaging transports to be supported in PHP, such as MQTT, WebSphere MQ or WebSphere Platform Messaging. Just one thing: I found that in order to get the most recent SAM release to work on Ubuntu on my MPC-L, I had to install IBM’s XMS client SupportPac (for some reason, it won’t build without it, even though it is “optional”) and I also had to delete a spurious empty line from the end of /usr/share/php/SAM/php_sam.php to prevent header issues. Other than that, it was all good.

The script is really simple and basically uses all of the defaults to create a connection to my local RSMB over MQTT. The advantage of this being server-side is that I don’t have to open my RSMB to the Internet, the PHP code can connect via localhost. Once that’s done, it creates a subscription on the topic I’ve asked for, and receives the first data that comes along, then echoes it back to the front-end. I could make it auto-updating with Ajax.PeriodicalUpdater too, but there’s no need to put a load on my server.

Wanna see a quick demo? 😉

I’m quite pleased with the way this is working. There’s some more plumbing to do, and I’ll almost certainly extend the server-side piece to allow two-way communications (publish as well as subscribe) as well as finer-grained control over the options. As a proof-of-concept though, I think this is looking good.

Aggregation using MoonMoon

One of my current side projects / tinkerings is the creation of a site which aggregates a bunch of my online feeds – an aggregated “identity dashboard”.

Jean-Francois made me think about using WordPress to do this. I love WordPress. It’s so ridiculously simple to install… provided you have a PHP + MySQL host, you just unzip, provide the DB login information in the config file, and then it initialises itself and has a nice administration dashboard. I played around with adding some feeds in widgets on the sidebar, and it kind of works. I can edit my own pages and I don’t have to use it as a blog.

Talking to Rob on Friday led me to experiment with Planet. Planet is built in Python, and generates static HTML pages. It is exclusively built for aggregating feeds together, and it works fine, but I have to go hack around in config files, setup a cron job, and so on.

Something I’d never heard about until today is MoonMoon. This is a PHP-based web solution (like WordPress) but it’s a simple feed aggregator rather than a CMS (i.e. similar to Planet). It doesn’t need a database. It’s at a fairly early stage of development, but if you pull down the latest code from Subversion you’ll find that it does have a nice administration page that enables new feeds to be added very quickly without the need to go near any configuration files.

Still at the tinkering / experimentation stage, but this has been an interesting exercise so far.