Modernizing Legacy PHP Apps with APIs

If you read the tech press, everyone knows they need an API but most aren’t really sure what it is. They treat it as another checkbox like “Web 2.0″ was a few years ago or a mobile app was most recently. In fact, there’s an entire “API-first” movement in development circles that most people don’t understand or even realize why. In this book, we’ll start by discussing the what an API is, why you might need one, and follow up with the how to build one.

Of course, how do you get your application ready for an API?

Modernizing Legacy Applications in PHP

Modernizing Legacy Applications in PHP

Unfortunately, your code base is a mess. It has been architected over several years by multiple different lead developers and it shows. There’ are no consistent patterns or structure. The oldest core of the system is a collection of include files running several levels deep. More recently, someone bolted on some class-oriented libraries, and most recently someone decided to try a framework rewrite. All of it was done in different coding styles, with different naming conventions. The codebase is full of files that contain a mixed-up aggregation of PHP, HTML, SQL, JS, and CSS. And the “tests,” such as they were, consisted of the QA team running over the site once or twice a week and filing bug reports.

But what if I told you it didn’t have to be this way? What if I told you there was a specific series of small, incremental changes you could apply steadily over time to make your PHP code better, more modern, and ready for an API layer to make integrations easier. Wouldn’t you like to have a plan like that written down for you, distilled into an easy-to-follow list of instructions?

Check out our new bundle “Modernizing Legacy PHP Apps with APIs” to learn how to prepare your application for an API and then design it properly.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

DrupalCon Austin Call for Presenters

DrupalCon Austin 2014

DrupalCon Austin 2014, June 2-6

For the first time ever, DrupalCon is joining us in the great State of Texas, specifically right here in Austin over the week of June 2nd-6th.

As a part of that, I’ve been tapped to serve as the Chair of the Coding & Development Track. It basically means that I’m in charge of reviewing every proposal submitted and choosing the content that falls into that track.. and towards that goal, I need your help.

I want to be flooded with great proposals so I have to make hard decisions and it generally makes my life miserable. ;)

You should submit if:

  • you work in Drupal, Symfony*, Composer, or related technologies;
  • you are doing something interesting on the Drupal platform;
  • you have integrated useful third party systems into Drupal;
  • you have done any work with Drupal 8, especially related to updating modules and/or development sites.

If you don’t do any of the above, don’t worry. You should know that although Coding & Development is my favorite track, it is only one of nine different categories ranging from Frontend to Business to DevOps.

If you have any questions, don’t hesitate to drop me a note, but make it quick.. the submissions close in just over two weeks on March 7th.

* You know Drupal 8 is Symfony-based, right?

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

What is Keith Casey Doing Now?

Since Twilio and I parted ways a few months ago, I’ve had a number of people ask “what’s next?” and for a while I didn’t have an answer. I just wanted to stop and catch my breath. In fact, I planned to take December off. That lasted all of 4 days..

Available from Leanpub: https://leanpub.com/restful-api-design

A Practical Approach to API Design

First, I decided to write a book on API design (pictured). After putting together an outline and realizing the sheer enormity of the project, I teamed up with James Higginbotham of LaunchAny who also happened to be working on a similar project. We first merged and fleshed out our outlines and then started writing. As of February 14, we’ve officially released the first version of “A Pragmatic Approach to API Design.”

Next, in order to support the book and other efforts, James and I have started building the API Developer Weekly newsletter.

In addition, I’ve kept my hands in a number of events including a pair of private hackathons and the nearly-infamous FU Weekend.

Next, I was tapped to serve as the Track Chair for the Coding & Development Track for DrupalCon Austin. As of today (Feb 18), the Call for Presenters is still open. It closes on March 7th.

Next, I started doing API design and development for a few companies. One I can share about is Techstars London company Op3nvoice. The premise is simple, what Google Search does for text, we can do for audio and video. We start with simple indexing and keyword analysis and peel back the layers to get emotional content and sentiment analysis. Overall, it’s a pretty freakin’ cool system and there’s a huge amount of potential.

And finally, I started doing a flock of API development in the Open Source space. I built a helper library for the new Marvel Comics API. I’ve started to formalize an API for web2project using the Slim framework and I expect it to be fully functional for our v4.0 release this summer.

So overall, while things have been exciting on my end, I can’t talk about the most interesting things.. yet.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

Operation Buy It Now

My first book – “A Practical Approach to API Design” – shipped this past Friday. As a result, I’m activating Operation Buy It Now today.

To sweeten the deal, if you order it by 11:59pm  ET on Sunday the 23rd, you will be entered into a random drawing for four hours of API consulting. All you have to do is forward me your receipt. My email address is keith@(this domain). (If you already ordered and didn’t send your email address, forward your receipt to me.)

On Monday the 24th, I’ll pick one winner and announce it via the APIDesignBook twitter account.

The consulting can include a review of your helper libraries, the API itself, or supporting documentation. We’ll kick things off with a call where you detail priorities and we’ll see how far we can get.

If you participate, make sure you also tweet out about it, post to Facebook, or spread the word however else you normally would.

Thanks to Paul Murphy of Op3nvoice for suggesting this effort.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

PHP5.5 and JSON Licensing or Licenses and You

Everything noted below is professional advice not legal advice. I’m not a lawyer, so check with your legal department or similar before you use open source software, regardless of the license.

In terms of software licensing, I have a simple principle:

Don’t make things unnecessarily complicated.

Let’s face it, most developers don’t understand licensing. They don’t understand copyright, licensing, or the rights and responsibilities that come along with them. In fact, some developers pride themselves on not knowing or understanding licenses at all.. they just want to write code.

As much as I wish we could live in that world, it’s wrong. If you’re sharing code in any way, shape or form, you need to understand the basics of the license you’re using and what the implications are.

Unfortunately, I did have to spend quite a bit of time and money researching licenses, acceptable use, and all the bits and pieces in between. You can read the details in “Why would we re-license Web2project?” on the web2project blog – but know that it was horribly painful and I wish it on no one.

For example, the PHP project was recently bitten by this line in the JSON library:

“The Software shall be used for Good, not Evil.”

which conflicts with the Free Software Foundation’s freedom Zero

“The freedom to run the program for any purpose.”

*sigh*

Many organizations have developed policies around which licenses are acceptable to use within their organization. They’ve reviewed the terms, done the homework, and cleared everything properly. They do this so you don’t have to.

But if you go with a non-standard license, you undo all of that work.

As much as the Pizzaware, Beerware, and DBAD licenses are entertaining and trying to make a point, they muddy things. It’s not because they are bad licenses, but because names matter in law as much as they do in computer science.

If your organization’s lawyers have said “you can use MIT, Apache 2, and the BSD 3-clause,” that means you can use those licenses and no others. If something is cited as the BSD 2-clause or Apache 1 license, they’re not interchangeable. After all, an array isn’t the same as a linked list though both are data structures to store items.

Whenever you’re writing code – any code –  that will be released publicly, make things simpler for the next person by choosing a standard license. One of the big three listed above are generally well-known but sticking to the OSI-approved license list is a good strategy too.

And people who don’t include any license make things even worse..

PS – If you’re trying to resolve the PHP 5.5/JSON library issue, this post from Iteration 99 has the details.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

Marvel API – Helper Library

Provided by the Marvel API

Provided by the Marvel API

It’s a dark and stormy night. You’ve been working on that last bit of code and an explosion rocks your living room. In walks Doctor Doom with a simple demand:

How many other “doctors” are in the Marvel universe?

Unless you’re Comic Book Guy and know this off the top of your head, you’re going to need a little help.. so with that, let me announce the PHP library for the Marvel API.

Overall, using the API isn’t a perfect experience but it provides a wealth of information in a mostly-consumable fashion. You can make individual requests to get all the information on your favorite Characters, Events, Creators, and even individual story lines. In a matter of minutes, you can retrieve all the information on all the variations of Spider-Man you can think of. Using the library, it really is only a few lines of code.

Unfortunately, you can’t search using the API. Unless you’re willing to iterate through results, you need to come up with exact matches. For example, “Doctor Doom” and “Doctor Doom (Ultimate)” are considered two totally separate characters with separate entries.

So back to our story..

There are really three steps to this problem. First, we need to connect to the service, then get a list of characters, and then figure out which are doctors.

This count statement gives us a total of eight doctors.. but remember that the API considered “Doctor Doom” and “Doctor Doom (Ultimate)” as two different characters. After we actually look at the names, we figure out there are actually only five doctors: Doom, Faustus, Octopus, Spectrum, and Strange.

If Doctor Doom ever comes knocking down your door, I hope this comes in handy. ;)

In the meantime, check out the Marvel API.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

Developer Evangelism: The Whole Story

Developer evangelism has been both the best and worst job in my career.

Before I go any further, let me state that I loved working for Twilio. It’s cool technology but more importantly the passion, intelligence, and the ability of the senior leadership and just about everyone else is amazing. I walked in and felt like everything we did sharpened my skills and abilities every step of the way.

I write this post for a couple reasons.. First, I’ve been out of Twilio for a couple months, so I’ve finally organized my thoughts.  Second, and more importantly, a number of people have asked me about becoming an evangelist and what the job is like.

First, what does a Developer Evangelist do?

This will vary from company to company and even as the company grows and matures, but here’s what I did:

  • Attended hackathons, gave demos, and helped people solve problems, Twilio-related or not.. an average of 1-2 hackathons/month for 2.5 years;
  • Update: It’s also worth noting that I co-organized 25-30% of those hackathons;
  • Spoke at an average of 15 conferences per year, usually a 1 hour presentation, sometimes a 3 hour workshop;
  • Wrote  blog posts ranging from technical coverage of clever applications and good API usage to event writeups;
  • For my first year, I ran customer support every Tuesday, then one weekend day/month, then not at all once the Support team grew;
  • Acted as a sherpa to help customers navigate the organization to find the right person to talk to for whatever;
  • Kept an eye out for good employee candidates, made recommendations where appropriate;
  • Tested and reviewed projects, tools, and concepts coming out of the Product team;
  • Introduced and promoted partners when their products/services fit the needs of other partners & customers;
  • Introduced customers to Sales, helped Sales by visiting customers and helping them get started;
  • Made myself available at random coffee shops both in Austin and during travels;
  • Served as the point of contact for numerous community organizations and (inadvertently) a number of F500 customers;
  • Traveled 140 days during 2011;
  • Traveled 120 days during 2012;
  • Traveled 115 days during 2013 (but over 9 months, instead of 12).

Next, let me cover the high points of Developer Evangelism..

The job is like nothing else. In fact, in the right company, it will be exactly what you make it. At Twilio, we reported through Marketing but we interacted with Support, Sales, Product, Recruiting, and just about every other group in the organization. My personal passion was helping people get started, figure out where Twilio made sense for them, and getting their first project online. But on any given day, if I was tired of doing X, there was plenty of Y and Z to do also. Unfortunately, at other companies, the evangelists may report through Sales which likely means quotas. Or through Product which means installs or downloads are probable goals. Regardless, measurement is good, but it has to be the right measurements and things you can actually influence.

The opportunity is like nothing else. Finding smart people doing cool things was my job. I got to meet, hang out with, help, and work with some of the best and brightest across North America. There are people literally saving lives with Twilio and that’s only the tip of the iceberg. When you can go to sleep at night knowing the world is changing in a positive way due to your work.. amazing.

The community is like nothing else. I don’t just mean the individual tech communities as those are awesome too. I mean the growing network of evangelists. No one gets the job without being smart, passionate, friendly, and being well-connected. When you get to hang out with this crew, you learn about some of the best and brightest out there and get to play with the best technology, concepts, etc.

Now, let’s cover the dark side..

First, the job is prone to burnout. I was the first evangelist to make it past the 12 month mark and I’d wager I really only made it to 18 months before burnout started to set in and 24 months before it fully reared its ugly head. Now before you think Twilio is exceptional in that way, know that it’s a common situation across many companies. I know of one company where evangelists consistently leave at 18 months.

Next, the job wreaks havoc on your personal life. If you’re single with no kids, no pets, no mortgage, no blah, blah, blah, the flexibility is awesome. You can be in a different city every single weekend and never come to your “home” city. I know of at least two evangelists who gave up their apartments for just that reason. But if you do have any of those personal commitments, it’s another story.. being in a different city every weekend can be a curse. You always have to make arrangements, make apologies, and figure out how to juggle.

The killer for me was when TripIt started reminding me of upcoming “visits” to Austin between actual trips.. for the record, I live there.

Finally, you are never off the clock. This is the big one.. and I can think of one friend and colleague who was nearly destroyed by it. When you’re at an event, you’re representing the company. When you’re speaking, you’re representing the company. When you tweet, you’re representing the company. Everything you write, say, do, or whatever represents the company. You can use those “doesn’t represent the views” lines all you want but they don’t mean anything.

Think about that.. from the time you wake up until you go to sleep, you’re on the clock.

So there it is. That’s the full story on Developer Evangelism. If you can do it for the right company and team, it is one of the best jobs you can ever have. At the same time, it’s challenging, exhausting, and ripe for getting yourself in trouble.

If you have any specific questions, feel free to drop me a note: keith@caseysoftware.com

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

Austin Tech Events, September 25th Edition

This is an ongoing list of upcoming tech events in/around Austin or especially relevant to the groups I participate in. It shouldn’t be considered perfect but is pretty good.

This is limited to approximately 90 days for sanity’s sake. Everything is in Austin unless otherwise noted.

September

  • 27-29th – Lean Startup Machine – a weekend experience validating or invalidating business/product ideas
  • 28-29th – Battle Hack Austin – a Paypal sponsored hackathon where the top prize is a literal battle axe. That’s opposed to a figurative literal battle axe.
  • 30-Oct 2nd – A List Apart Austin – The design conference for people who make websites.

October

  • 6-8th – Captivate Conference – a conference focused on further blurring the lines between musicians, game developers, and other creatives
  • 7-10th – ZendCon in Santa Clara, CA – The biggest PHP conference each fall
  • 7-11th – Austin Startup Week – it’s like SXSW but less social media and more people doing things
  • 18-20th — Central Texas Givecamp – it’s the hackathon for non-profits looking to fix or improve their technology systems
  • 18-20th — HackOut Austin – The first nationwide GLBT hackathon
  • 22-24th – TNRIS’s GIS Forum – The place for GIS information, training, and discussion
  • 29th – Tech Stars Austin Demo Day – The inaugural Demo Day for the Tech Stars Austin program. This will wrap up 12 weeks of work including planning, research, development, and sales.

November

  • 15-16th – HackTX – The biggest student hackathon in Texas
  • 22-24th — Startup Weekend Austin – The weekend bootcamp for learning the ins and outs for kicking off a product or even a company

December

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

Austin Tech Events, September 12th Edition

This is an ongoing list of upcoming tech events in/around Austin or especially relevant to the groups I participate in. It shouldn't be considered perfect but is pretty good.

This is limited to approximately 90 days for sanity's sake. Everything is in Austin unless otherwise noted.

September

  • 17-19th – TwilioCon 2013 in San Francisco – If you're working with or building on the Twilio platform, this is the event for you. There is something for everyone with technical workshops, a business track, and after parties.
  • 19-21st – RESTfest in Greenville, SC – This is one of the single best places to get into the details of REST and hypermedia concepts. It is not for the feint of heart but definitely open to newcomers who are willing to learn.
  • 27-29th – Lean Startup Machine – a weekend experience validating or invalidating business/product ideas
  • 28-29th – Battle Hack Austin – a Paypal sponsored hackathon where the top prize is a literal battle axe. That's opposed to a figurative literal battle axe.
  • 30-Oct 2nd – A List Apart Austin – The design conference for people who make websites.

October

  • 6-8th – Captivate Conference – a conference focused on further blurring the lines between musicians, game developers, and other creatives
  • 7-10th – ZendCon in Santa Clara, CA – The biggest PHP conference each fall
  • 7-11th – Austin Startup Week – it's like SXSW but less social media and more people doing things
  • 21-24th – ESRI's GIS Forum – The place for GIS information, training, and discussion
  • 29th – Tech Stars Austin Demo Day – The inaugural Demo Day for the Tech Stars Austin program. This will wrap up 12 weeks of work including planning, research, development, and sales.

November

  • 15-16th – HackTX – A student-focused hackathon but all are welcome

December

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub

PHP and Twilio on Google App Engine

As of Google IO this year, Google App Engine officially supports PHP. While it’s still in beta, you can tweak your applications and give it a try right now. I’ve included some of my lessons learned from getting Twilio’s quickstarts functional on GAE.

You can read the results here: Getting started with Twilio on Google App Engine for PHP.

And I also have a followup being published with php|Architect in the next month or two.

Are you interested in API Design? Check out our new book "A Practical Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available now from LeanPub