The BASIC Cloud Framework API

Last night, I spent the evening with a bunch of PHP developers in DC. This informal gathering in the DC-PHP community is a regular occurrence known as the DC PHP Beverage Subgroup – Virginia Chapter. There is also a DC-chapter that meets once a month as well. These two informal gatherings are for the sole purpose of getting together, enjoying some food and cold beverages and generally just talking about anything and everything. It complements the official DC PHP meeting which is generally a technical presentation directly related to PHP.

So last night, we were yukking it up about how PHP has re-invoked the GOTOoperator, a programming mechanism that, we thought, died with the BASIC programming language of yore. Coding in BASIC was very procedural and not very rich in its abilities.

1
2
10 PRINT "Hello World!"
20 GOTO 10

One of our number suggested that PHP, since they regressed so badly with the GOTO operator inclusion, should also adopt line numbers in code as well. :) This conversation devolved into all the cliché buzzwords of our time and eventually, it was suggested that what we really need is a “BASIC Cloud Framework API”.

Putting aside BASIC, which is not really practical or desirable, the concept of a Cloud-based Framework API, whatever it actually is, is not all that undesirable. If you think about it, we already have a Cloud-based API for APIs (yes, I realize this is very meta) with the super-cool Gnip which we covered last year when they launched. Social services channel their data through Gnip and Gnip provides a single API layer for data access. And it’s built in the cloud.

Similarly, up until a few years ago, Javascript was painful to write because developers had to write code for all the browsers and all their nuances. That was before Javascript libraries — or APIs, if you will — like Prototype or jQuery came along providing the developer with a single layer of javascript programming that would work seamlessly on all browsers.
1206677_75532165
The concept of single layer APIs is not a new one. Why can’t we have an API for cloud-services as well?

Think about this. Right now, anyone wanting to build an application has three options. They can build out a server cluster or farm that physically scales and, by proxy, ends up costing a lot as physical hardware costs a lot. A second option would involve a virtual cluster made up of virtual machines. You still need hardware, but each server souped up with up to 32G of RAM can theoretically host tons of virtual machines all acting as a physical server. An entirely virtual solution is hosting applications in “the cloud”.

Cloud computing is not without it’s challenges. I’ve challenged the reliance on it in the past, and I still do. However, with cloud services like Amazon’s EC2, S3 or Google’s App Engine, it becomes entirely possible to not only store data in the cloud, but also run and maintain entire services in the cloud.

The problem is, each of them require different things. Amazon has a suite of developer tools that are needed to build against their cloud offerings. Google App Engine only supports Python, Ruby or Java.

There should be a way to abstract this development to a single layer — or API, if you will — to take advantage of this.

Laugh it up, chuckles. A cloud-based framework API is not all that ridiculous of a concept. The world once thought the earth was flat as well.

Read More

For PHP Devs, a Twitter PHP Class

At the end of this post, this site is going into a twitter free period of two weeks. I’m sensitive to the fact that we talk about Twitter quite a lot and not always doing a good job of reaching into all of real life like we’d like. So after this post, Twitter will not be mentioned here until June 12. :-)

However, I wanted to get this out the door for devs to knock on and bang out. Awhile ago, I created the dctwits Twitter group and released the generic code. It included a Twitter class created by David Billingham and slightly modified for our use.

A few days ago, I released the WP-Twitterpitch plugin which also used the same class. It’s a very useful class but, to be honest, was a little messy, didn’t support XML and JSON and didn’t have support for all the Twitter API.

So I cleaned it up, extended it, fleshed it out a bit more, brought in Keith Casey as a developer and we’re basically launching the class as a version 1.0-beta today.

I’ll work on documenting things a bit more but there is some basic usage on the site and the code itself is pretty well documented. I need testers to bang on this code and submit issues back, via the Google Code page. Patches welcome as well. And I’d love to see how you use this. You can download direct or via SVN.

When Keith gets done with the DC PHP Conference, we’ll look at pushing it out as stable.

Read More

WordPress Export Base Class

Real quick note to let you know that over the weekend, I released new code that is GPLv2, relating to WordPress export format (WXR). The code and details are here and I’d love to get some input and contributions of other export classes. I’ve included a (yet undocumented) Expression Engine exporter as well and will back port some of my previous exporters to use this class as well.

So, if you’re a WordPress hacker, or if you just want to help people move to WordPress and have some coding skills, half the battle is already fought. Check it out.

Read More