This past week I needed to be able to read some data from a Google Sheet and then update a column for each row after processing it. This sort of thing should be simple, Google is built on APIs and has client SDKs for just about every language. I’ve also integrated with several Google Admin APIs previously so I expected this to be a breeze. I was wrong. I started out by reading the Quickstart for Sheets API with the PHP Client, but almost immediately I could tell it was not written for my use case.
Last year at php[tek] 2015 during the hack time I messed around and created a Docker image to run and test PHP7. It was surprisingly easy and I quickly learned that the app I was working on at the time ran fine in PHP7, good deal. So since then I’ve been awaiting the general availability release of PHP7 to move forward with upgrading my apps. The main thing holding me back was I just didn’t want to maintain an image based on compiling from source.
This is Part 4 in a series, you can read Part 1 here or Part 2 here or Part 3 here or Part 3.5 here. At this point in this series we have a complete PHP client for the Nexmo APIs. Hopefully I’ve been able to teach some good practices and designs in the process of developing it, but I know many of you test-driven-development advocates are probably screaming that I’ve left out the most important part: testing, and testing early.
This is a small follow up on Part 3 in a series, you can read Part 1 here or Part 2 here. In Part 3 of this series we completed API clients for Nexmo’s SMS and Number Insight APIs. Today I implemented the rest of the clients for Voice, Number Verify, and Developer APIs. As I’ve hit on several times, using the Guzzle Web Service description way of developing an API client can save a lot of time.
This is Part 3 in a series, you can read Part 1 here or Part 2 here. Ok, quick recap: in part 1 we explored what API calls to the Nexmo API look like to send an SMS and a few ways we could write them. Then in part 2 we built out the ground work for a Guzzle web service client and implemented the Send SMS API with it.
This is Part 2 in a series, you can read Part 1 here. In Part 1 of this series we laid a foundation for consuming the Nexmo SMS API and covered a few ways to interact with it. In this part we’ll create the actual Guzzle Web Service Client to interact with it to demonstrate how simple it can be. The first thing we’ll do is get our project space ready by creating a folder (these steps assume you’re working on a Mac or Linux based system):
Phew. That was a long title. Sorry about that, just wanted to try to be clear on what this post (series of posts) is about. Recently I’ve had the need to write several API clients to simplify integrating with services like CrashPlan, Smartsheet, Trello, etc. Initially I started writing a client library that used the standard Guzzle features. After writing a couple of them I remembered a talk by Jeremy Lindblom @jeremeamia at last years php[tek] conference.
Wordpress is pretty awesome, but sometimes it just doesn’t do exactly what you want. Thankfully the API is pretty extensible and you can change just about anything you want. Right now I’m working on a site for a department at our organization and for their site they really need to host four sites (sections) in a single install. They would like to have a global navigation element to click between the sections but then they want each section to have its own main navigational menu.
For must of my time working at WebEx I was either support or developing with their APIs. The WebEx APIs are used to schedule meetings, create users, gather history information, etc. I can’t tell you how many times I wrote new code to do the same things. So when my current project with Sumilux came about to write integrations for Cisco WebEx, GoToMeeting, and BigBlueButton APIs we decided to just write one library to integrate with them all.
I’ve been working on refactoring my adapter to prepare for supporting many of the features I discussed in my previous post. Involved in the refactor was moving code that should be common to any of the realtime translation adapters to a common parent class, Shipley_Translate_Adapter_Realtime. So now the usage is a little different when creating the Zend_Translate object, but the usage within the view remains the same. Also in this update I’ve added some Zend_Log support for Zend_Log_Writer_Firebug so that I could easily do some debugging while moving all this code around.