Monthly Archives: June 2013

Keeping the faith in Shoreditch Village Hall!

Last month, my friends at Shoreditch Works (a pair of amazing co-working spaces in the Silicon Roundabout area) ran a Kickstarter campaign to support their goal of repurposing an empty warehouse building in the area into a “Village Hall” – a place to run events, offer community time, mentor youngsters, help startups, etc.

They crushed it with the the campaign, raising well over their original target, and ended up with funds to do things like offering free desk space to local startups, and apprenticeships in community management.

We had a small celebration towards the end of the fundraiser, a few weeks back, and I said a few words. You can hear some of them in the video below. I said some other things too that were far more emotional and gooey than I may have intended on the night, but it was off-the-cuff.

Yesterday, the team heard that it’s unlikely that the building they had originally targeted will now be available, as the lease has gone elsewhere. The hunt begins for an alternative, suitable, location.

I know this is a huge blow to all of those involved, who worked hard both on the campaign, and on all of the logistics and preparations around the creation of the new space. Of course, it is also disappointing to many of us who backed the Kickstarter and hoped for the Village Hall to be opening in the next few months.

To the team, I say this – exactly what I said on the night of the finale – I believe in you. We believe in you. This is going to happen! Shoreditch does need exactly what you had in mind, and I know we as a community can still make it happen. A setback? yes, but just a setback, nothing more.

Let’s do this thing!

 

Advertisements

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!

 

Busy times, but let’s talk Cloud Foundry!

Users of the existing beta Cloud Foundry hosted service cloudfoundry.com were sent emails this week explaining that we are almost ready to launch version 2 of the service. If you’re a current user, or if you have signed up in the past, dig through your inbox filters for the email (mine ended up under the “Promotions” label thanks to Gmail’s auto-filing magic).

Cloud Foundry v2, sometimes known as “next-gen” or ng, is a big set of updates. I wrote about some of them in my last blog post, and also noted there that we are going to run the new version on AWS.

Some of the things worth getting excited about are:

  • custom domains (the number one thing I’ve been asked for after every talk!)
  • buildpacks – the ability to use “any” language, framework or runtime that has a buildpack, not just Java, Ruby, or node.js (Matt and Brian seem to be competing to find interesting ones!). By the way, you should totally be trying your Spring and Groovy apps on v2! 🙂
  • organisations and spaces – the ability to share apps with a team and collaborate
  • a web management console for your apps
  • a Marketplace, which we will be expanding over time, allowing you to bind third-party services in to your applications.

These are all big changes, and there are many more under the hood (Warden, a new staging process, a new router… it’s a very long list).

My colleague Nima posted a nice slide deck giving a more technical overview of some of the internal changes:

In addition, our demo ninja Dekel has shared a great video of some of the things you can expect from version 2:

Over the past 24 hours or so I’ve been doing my best to respond to questions on Twitter and elsewhere. The existing v1 version will go away on June 30th, so if you are using it now you’ll want to look at migrating apps in the next couple of weeks, and we’ll share more on that soon. The new version will have pricing attached, with a free trial period too. Of course, the code is always available on Github and you’re free to spin up your own CF instance running on AWS, OpenStack or vSphere.

I know folks will have many more questions about the specifics over the next week or so, and we will be looking out for them.

Supercharging the community

As we have grown closer to v2 release, there has been ever-increasing activity in the vcap-dev mailing list and around the community. We’ve had more and more code contributions (so much so that I recently wrote a blog post about how you can contribute to the CF core projects). Projects like the cf-vagrant-installer and cf-nise-installer are helping people get local environments running very quickly. Our friends from PistonCloud released their turtles project. Best of all, the super Dr Nic Williams recently set up a cloudfoundry-community organisation on Github to act as an umbrella for many of these community contributions (info on how to join is here).

Let’s talk! (in London)

Over the past year or so I’ve spent a lot of time out in the developer community in London, and it has become apparent that a lot of folks are interested, already contributing to the community, or in some cases, already running their own CF instances in production 🙂

So, I thought it would be a good idea to do some bridge building and bring folks together to get to know one another. A brief unscientific Twitter poll suggested that other people liked the idea, so we’ve stuck a stake in the ground (evening of July 3rd) and I set up an Eventbrite page for a meet up. If you’d like to chat with people about Cloud Foundry over a drink, do sign up and come along. I’ll sort out a venue in the next couple of weeks, but I imagine it will be “around Shoreditch” or possibly over towards Waterloo, for purely selfish reasons! Totally informal, this is just a community meet up, so I’m not planning to do slides and talks and stuff – just come and share ideas or ask questions!