Friday, June 18, 2010

LiteFramePHP

is now out...

LiteFramePHP

This is a small MVC, PHP framework that is built out of a single object. It may be small but it certainly has many features that you'd find in a full-fledged MVC framework such as CakePHP.

The site hosting the files was quickly thrown up, so there still is a lot to be done. Mainly, the documentation!

More to come...

Wednesday, June 9, 2010

Open Sourcing

I admittedly look at the Open Source movement as one that parallels a spirtual or NGO cause. At the core of it, there isn't allure of money that drives people to work hard and then to share their ideas openly. Something about that tells me that the movement as a whole is greater than the sum of its parts, and this is shown every day with more and more code that is available for use. I owe an incalculable amount of my development and knowledge to this movement, and I didn't have pay a penny if I so choose not to. I've probably learned more through Open Source on development than my time in college.

It is time for me to become one of the parts of this movement. I want to attempt to give back freely what I have taken away in hopes to help out others; at the very least to support the movement. I must admit that I am quite nervous though, I am exposing my ideas and code which I usually am very protective of. They will be open to ridicule for those that choose to use my code.

I've been working on two different frameworks with a buddy at work that includes quite an extensive amount of different modules. To give an idea, we probably have roughly around 8-10k lines of code. First, a php, super lightweight framework. Yes, I realize that the world might not need yet another php framework, but after using MVC frameworks such as Cake and Zend I was blown away at the size of the framework that was needed to get up and running on a new project. The challenge was to keep this framework as light as possible while sill providing all of the necessary functionality. I think that we did a pretty good job. The time that it took to develop probably equaled the time that we talked it over and this is usually a good thing. Hopefully that'll be an indication of the quality.

Next, a series of plug-ins that are piggy-backing off of jQuery. This is probably what I'm most proud of. I believe the code quality to be fairly strong. We are using some fairly new, a bit advanced, js code development to keep the code super clean, flexible, and any other buzz word that you choose to insert. It has always been a challenge to develop javascript with the same mindset of true OOP, not just one or two objects that might have a private function/variable that is thrown in there for the novelty of it.

Some of the next major steps will be documentation. If I hope others to use, I need to provide information. At any rate, I hope to release both of these frameworks by the end of the week for those that don't need documentation.

Here is to exposing my brain. Cheers.

Monday, June 7, 2010

Web Hooks

I've been doing a lot of API integration work lately. Mainly my days have been spent trying to master Google's Adwords, Yahoo's Search Marketing, and Microsoft's Bing. On top of that, a large chunk of my time has also been involved in Mail Chimp and Paypal's APIs. Dealing with these different APIs requires an incredible amount of reading which in turn requires a decent amount of time. The purpose in dealing with all of these APIs is to automate processes which allows for incredible scale with zero overhead (other than the guy writing the software).

I am able to trigger events that these 3rd party companies have if a change comes through our system. I am limited in having these APIs, which have no idea about each other, communicate with each other based on an event that *they* might receive. Confusing?!

An example of this could be the event of a user unsubscribing from our mail list through Mail Chimp, which handles all of our mailings. Since a user unsubscribes from Mail Chimp, I have it such that that event would trigger Mail Chimp to send me the information of that event (e.g. user's name, why they unsubscribed, date they unsubscribed, etc) to a URL that I have set up (like an event listener) that processes these 3rd party events to update our system appropriately. So in this example, when I get information on Mail Chimp's event, I might change the value of the user in our database to let us know that they are off our mailing list. These are called "web hooks".

This is great. I am now processing information based on events that are outside of my system. Now you can start using your imagination on having 3rd party events starting to interact with other 3rd party systems. Continuing with the previous example, we can take the unsubscribed user that we got information on from Mail Chimp and check our database for their action based on Adwords and then update our Adwords automatically to reflect the change in our system based on the unsubscribed user. Now I have events from one system impacting how I treat another one, all automatically.

APIs were a huge step in allowing for automation, but they can only take you so far. APIs are only half of the puzzle. Web Hooks are the other half. Now APIs can be connected together through custom HTTP Post callbacks. This idea isn't new, but I'm starting to see it gain sizable traction in the web. Hopefully developers developing new APIs will keep web hooks in mind when building.