Future Development

Being a developer is an interesting as well as an extremely frustrating job. I could work two weeks on a project with an additional two or three days debugging for my five second pay-off. As crazy as that might sound, I could not imagine doing anything else (except for maybe music or art....or philosophy...or even cultural studies).

Being a programmer, and more specifically web developer, has it's share of interesting problems that I couldn't find in any other field. This is the only field that I've come across that has new paradigms, revolutions, and shifts every couple of years if not faster. This requires an extensive amount of reading and research to stay at the top of the field consistently. Due to the reinventing nature of the field, traps and pit-falls can easily happen to the best of us. Either reading too much, which only allows for a theoretical approach without implementation or experience to reading too little which puts one behind the rest of their peers is a hard thing to balance. When reading the latest and greatest technology out, how does one know whether invest time into learning or simply just skip over? I struggle with this constantly.

By trade, I'm a PHP developer. The platform that I build on is an ever-changing, fast-paced one. But there is one thing that seems to make itself extremely obvious in the future of my field: javascript. Yes, this may sound like old news to some because javascript has been out since the mid '90s, but with the trend of where the Web is going, only recently javascript has started to make huge leaps and bounds ahead of anything as a staple of future web development. Tools such as jQuery (yes, also been around since the mid 2000), node.js, and many others has A) brought development with javascript to an extremely high level, B) development possible on the front end as well as the back (yes, all ECMAscripts are agnostic in theory, but the practice of such was rare) and C) it has branched out to mobile development such as pure scripting game engines, jqtouch, phone gap, and many others.

I've always been decent enough in javascript to get done what needed to get done, but lately I've been spending the majority of my time learning the language's popular design patterns and best practices. There is a wealth of information out there to turn a novice into an experienced developer. I've been spending some serious time developing jQuery plugins because I truly believe that my work will last longer in javascript than any other technology at the moment. It is a gamble, but I think it is a safe gamble.

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.