30 Minutes with Paul Reinheimer

      2 Comments on 30 Minutes with Paul Reinheimer

p. !>http://farm1.static.flickr.com/92/242046349_7cf6e8948c_m_d.jpg (Photo By Sebastian Bergman)! Many of you will recognize the name Paul Reinheimer as the primary instructor for “php|architect’s”:http://www.phparch.com/ “training classes”:http://hades.phparch.com/socrates/. Others will recognize him as one of the two hosts of the podcast “PRO::PHP Podcast”:http://podcast.phparch.com/main/index.php/main. Still others know him as the author of Professional Web APIs with PHP from Wrox Press. The only book I’ve ever seen to get such a “colorful review “:http://funkatron.com/index.php/site/comments/paul_reinheimer_will_fuck_you_up_and_steal_your_woman/ from Ed Finkler. If you do know Paul, either in person or on-line, then you know that he always has a smile on his face and he is never too busy to help you with a PHP issue.

p. I had the pleasure of sitting down and talking with this young but rising star in the PHP community last year at php|works. Now, after sitting way too long on the shelf, I’ve finally had enough time to finish this interview and present it to you.

h3. How did you get into programming?

p. A long time ago, my parents owned a Commodore 64. My mother brought home for me this large purple book, almost like a coloring book. It was a series of programs that you could type into the computer. I really liked that and I had a lot of fun with it but they were really long to type. My parents apparently his the source code disk for the book. Through the process of typing these programs in, I began to learn which lines of code I could skip and have things still work and which lines of code I couldn’t. So that kind of got me more interested and eventually I started writing my own applications in BASIC. I moved from the Commodore 64 to a 486 and I started working with QBasic and Microsoft’s Quick Basic on it. When I was in High school, I worked in Visual Basic. Once I went to University I moved into java, C and all that fun stuff.

h3. Ok, so how did you go from University and programming in Java and C++ to dynamic languages and specifically PHP.

p. I was working for MetaMachine, the file sharing company that published eDonkey. At that time we were running phpBB and we had one of the largest install bases out there. However, we were having a lot of problems with it because it wasn’t scaling that well. It also wasn’t handling upgrades that well either. So I dug into it and made things work better for our size of an installation. That was my first experience with PHP.

h3. Since MetaMachine, what have you been up to?

p. !>http://farm1.static.flickr.com/225/511836058_c8d7d25a20_m_d.jpg (Photo By Sebastian Bergman)! I left MetaMachine at the end of the summer of 2004. While I was there, I landed the book deal to write PHP Web APIs. I currently work for PHP Architect doing their training both on-line and off-line. I am also working on some other book projects as well. I also continue to do freelance consulting on the side.

h3. Let’s talk about your book. What was your first introduction into APIs?

p. I had been interested in them for a while and I had heard about the Google API for searches and that sounded cool. I had been working on something like that with MetaMachine, we were trying to implement searching across all our domains. The book opportunity came along. I was approached and told that they were looking for someone to write a book like this. So I researched it a bit more and discovered that it was something that I was really interested in.

h3. Let’s talk about APIs at the moment. What has been your biggest problem when dealing with APIs?

p. I think the biggest problem I’ve run across is when people go their own way and not build on one of the standards. Also, in most cases, the documentation for the APIs is usually horrible. Some APIs only offer the source code as their documentation. Only slightly better are those APIs that offer one or two examples as their documentation. They will say “This is how we did it in VB or this is how we did it in Java.” As a PHP programmer, I then have to go in and figure out how to convert that example to PHP. For some reason, not many APIs have PHP source examples. So the docs are bad and the only answer for “How do I use this in PHP?” is “Just look at the source code.” Those are the biggest problems I see.

p. While I was working on the book, I needed to access the FedEx API. Living in Canada I was trying to go through FedEx Canada. I was looking for information non their documentation and how to get setup on their development zone. So I called them up and talked to my account manager. He gave me the names of the right people, I talked to them and they said “great, we’ll send you the Non-Disclosure agreement and once you’ve signed it, we will give you access to the documentation.” It took my by surprise. The whole point of an API is that it’s open and it’s easy for people to get access to; a NDA kind of ruins the whole thing. I tried to explain to them that my book would help them. People would see that FedEx has an API and is a choice. They responded with a “No.” They said I could talk to the manager see if I could get permission, etc. There was a list of steps I had to take.

p. Then I went to the American version of FedEx. All of the documentation is public on the website there. You go to FedEx.com, you follow services for a couple of links and you get the documentation. It’s the exact same documentation. So in the end, I ended up getting an American friend to sign up with FedEx and getting an American account and I did all my development via that.

p. I will say this in FedEx’s defense though. You can call them on an 800 number and get someone that will answer your questions about their API. I didn’t sign up for service or anything but I was about to speak on APIs and had a question. It took me about 10 minutes to call them and get the answer I needed.

h3. So in your book, you talk about FedEx and Amazon. What are some of the other APIs you deal with in your book?

*(disc) eBay
* Google’s Search API
* Flickr
* del.icio.us
* and Paypal.

p. I was actually pleased with the way PayPal worked. It is still complicated; I had to go get a SSL certificate for myself to make sure all communications were secure. The way Paypal works is you don’t always have to go to them. Sometimes they will ping you to let you know that you’ve received money, how much and from whom. Then you go back to their API and you can ask the question “Did you really tell me this?” and they confirm it and you can process it from there.

h3. What is your favorite API to work with?

p. I really had a lot of fun with eBay’s API. I’ll be honest, I had to re-write that entire chapter. They deprecated my schema after I finished the chapter. So I re-wrote the entire chapter. I wasn’t willing to go to market with a book that had content that was out of date. Overall though, it’s still my favorite. There is a lot of power in the eBay API. There is also a lot of complexity. They do a wonderful job though. When you compare eBay and Google, Google has it easy when compared to eBay. Google doesn’t guarantee that if you run the same search twice, you’ll get the same results. They don’t even guarantee that if you run the same search in two different countries that you will get the same results. eBay on the other hand has to return identical results, worldwide and it has to be up to the second. I think they are doing their job really well and I’m impressed with them.

h3. Other than the fact that Wrox Press asked you for a book, what was the driving purpose behind writing the book?

p. When I started writing the book, my goal was to write the book on APIs. Readers were going to be able to take this book, copy the code and presto, they are talking to Amazon, Flickr, Google whatever their application needed to talk to. As I started writing the book though, I realized that the problem with that approach is that people are always going to need to refactor the code. It’s never going to work exactly like you need it to by just copying and pasting. In some cases, it was a lot of code to copy and paste too. This method didn’t really teach people how to work with APIs, it just gave them the answers.

p. I also discovered that as I was working with these APIs, I was spending a lot of time trying to make those first couple of calls. Once you have the “hello world” working, your developer keys, etc everything else is simple.

p. Because of these two thing, I changed the direction of the book. Rather than be the end-all-be-all of an API book, I took the approach of “These are the first 6 calls you will most likely make against Amazon and here’s how to do them.” From there you can go do whatever you need to do because it’s easy to make the 7th call because you now understand how the first 6 you did worked.

p. When you were working with your code, were there any pre-defined classes or pre-written code that you used?
I used NuSOAP. I had the opportunity to use the PHP 5 built-in SOAP support but chose not to. Doing so would have abandoned all the PHP users that are still using PHP 4. From a publishing standpoint this was not what we wanted. So I used NuSOAP. I was very pleased with their mailing list and the short time it took to get answers to questions posted there. It worked really well for me.

p. The other advantage of using NuSOAP over PHP 5’s built in SOAP support is that it supports automatically building your WSDL file. So rather than manually having to build that and provide it to the application kit will do that automatically for you.

h3. What other tools did you find useful in working with APIs?

p. !>http://farm1.static.flickr.com/213/503497551_0e4309caec_m_d.jpg (Photo By Ed Finkler…used by special permission)! If you Google for a generic SOAP client, I think the first hit you will get is something like SOAPClient.net. You use this tool by pointing it to a WSDL file. It will then generate this big long form that will build your request for you. So in situations where I was having trouble making that first call, I would use the form to build the request for me and just print that out. And compare that to what I was doing to see where I was going wrong. I like that one a lot and I kept coming back to it.

h3. What is the one technology that you find exciting?

p. I think the name for it is COMET. I am really interested in that and want to learn more about it. I see the Ruby camp doing a lot of exciting things with it and I want to learn more. Comet is an HTTP transfer mechanism. If I understand it right, it uses transfer encoding ‘chunked’ and your client maintains a persistent connection to the server through which it will keep sending data when it’s available. Under the standard Ajax methodology, your script may make a call back to the server every thirty seconds to try and keep itself up to date. With Comet, the server can update the client whenever there is new information. That may be every four seconds, every ten minutes, or variable lengths.

h3. Finally, What is the one blog that you have to read every day.

p. Honestly, I read “pennyarcade.com”:http://pennyarcade.com every day. It’s a gaming comic site.