When working with serverless actions, often we'll still need to access some sort of service, whether it's object storage, a database, or whatever. Here's a quick overview of how this works for IBM Cloud Functions (plus some gotchas ....) Continue reading
One of the best features of CouchDB is its change feed which allows us to get a feed of the changes happening on our database. It's also possible to have a serverless function (examples are for IBM Cloud Functions but should also work for Apache OpenWhisk) that fires in response to activity on that change feed. I have a database of events that I want to react to when they happen, but the change feed doesn't include the actual document that was added - but you can add one of the built-in functions to a sequence to make that happen. This post will show how to achieve this by wiring up a built-in action to fetch the document with another action of our own that then handles the data. Continue reading
Did you know you can serverless with PHP? OK, so serverless is clearly not a verb, but since I love serverless tech and have also loved PHP for longer than I'm going to admit (the dates of the earliest posts on this blog might serve as a clue), using these technologies together is definitely my idea of a good time.
I included an example of a serverless endpoint to receive incoming webhooks in my talk at PHPUK last week and I got a few questions about it so I thought I'd share that example in written form. Continue reading
I'm a regular and happy user of Apache CouchDB, so much so in fact that I'm writing a library to talk to it from PHP. While working on tweaking a feature, I realised that the laptop I use for development didn't have the right/enough data on it to test this particular thing - but that I had a suitable database on my other laptop. Copying data between CouchDB installations is very easy because it has an HTTP API, but usually when I do this at least one endpoint is web-accessible. Enter one of my favourite tools: ngrok.
Ngrok allows me to make the CouchDB on one machine visible to the world (with all the security caveats that this entails! It's a random URL, never leave the tunnel open longer than you need it, etc) with a command like this:
ngrok http 5984
This opens a tunnel to my local machine on port 5984 which is CouchDB's default port. I'm running a local dev instance that doesn't need a username or password which makes this simpler if not exactly secure. I get a gobbledeegook ngrok URL that will allow anyone, anywhere to talk to my CouchDB.
Then I went ahead and on the other laptop, used the web interface to start replication from the sample products database on the local machine over to the one on the ngrok URL.
As soon as it starts, the first laptop shows that there's traffic coming over the ngrok link - and a few minutes later I had the database I wanted and can go ahead and work on this feature.
I have the pleasure of using Slack Enterprise Grid on a daily basis as IBM has adopted it internally, I work there, and there are far too many of us to use a single slack instance. The main downside of Slack Enterprise Grid (apart from having about 15 slack organisations running in your client all the time) is that it returns different data when integrating with the Slack Web API and RTM (Real Time Messaging) systems. We had some bot integration that stopped working as a result, and I ended up moving to BotKit and then using a mixture of the RTM and Web API from Slack to get things to work. I won't remember how I did it so I thought I'd better write it down. Continue reading
I'm working on a CouchDB library for PHP, and so I needed to write some tests for it. CouchDB has an HTTP API so I'm basically making web requests and while I could certainly set up a test database and run full-on integration tests, there are a few limitations with that approach. Firstly: it means I'm testing the database as well, which isn't what I want and brings extra dependencies that make the tests harder to run. Also: I want to be able to test error cases, rate limiting and so on, that would be difficult to recreate reliably. Continue reading
I'm not a huge fan of the live demo in conference talks - it's really hard to do well so I see a very large number of bad ones. Also, it's super hard work to include them in my own talks in a meaningful way because they are so difficult to pull off. I could write a very long list of reasons not to ever live demo (nobody wants to watch you type, now you are talking to your laptop, conference wifi rarely works, you could tell me three much more useful things in the time you've spent doing this ...) but in truth as developers we love the "new shiny" and it can be super helpful to get an actual walkthrough of how to do a particular thing. So if you absolutely must live demo, here's my own general plan and tactics: Continue reading
Most of the PHP I write runs on Bluemix - it's IBM self-service cloud, and since I work there, they pay for my accounts :) There are a bunch of databases you can use there, mostly open source offerings, and of course with PHP I like to use MySQL. Someone asked me for my connection code since it's a bit tricky to grab the credentials that you need, so here it is. Continue reading