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.
The other day, I was talking to the CTO of a company that is working to build a web technology solution for a problem that exists due to the arcane infrastructure and systems already in place in the niche target industry. He was mourning the fact that, after spending gobs of time wireframing and re-wireframing a solution, the parties who initially expressed interest in licensing the technology, had decided to walk away from the table for a variety of reasons.
The big conglomerate that had decided to walk had expressed concern over the fact that they already had systems for billing and other management aspects of their company and didn’t want to invest in something unknown and untried over their long-standing, yet antiquated, solution.
Over the course of an hour or so, and even since then, we looked over his wireframes determining what the company should look like in order to make some sales, if not all the sales he wanted. I realized that his product was designed in such a way that dependencies were created everywhere. If a customer wanted just this one portion that does employee management but not the other part that does billing, there was no productive way to do this so he could make a sale without making the big sale.
In the web world, we talk about mashups. Take a google map and mash it up with Twitter and you have Twittervision. Mashup Basecamp with FreshBooks and tie in Salesforce and you’ve got a complete back-office CRM-Billing system to build your company on top of.
The strength of mashups is the distributed nature of the work. I no longer have to store my own video files because YouTube will do it for me and give me a means to access it, thus eliminating the overhead and cost of doing business associated with that video. I no longer have to worry about the development time and money needed to distribute a widget containing my content to other websites because Clearspring does that work for me. The trick is in APIs which allow others to innovate on top of the technologies created by others.
My advice to this entrepreneur was to create APIs between his various modules and build out-of-the-box products that he could sell that utilize those APIs. In fact the APIs can be open and still be paid access, which provides another stream of revenue – especially when his clients have the money to pay top dollar for those APIs if they consider the alternative cost of throwing out entire chunks of their existing infrastructure and using an out of the box solution that may not meet their unique needs.
It probably interests no one but me, but I’m becoming more of an SVN ninja. It took me days to figure out how to setup a web accessible SVN server with appropriate web, svn and filesystem permissions (i.e. this repository is world readable, but can only be written to by me). I’ve been using SVN on the client side for a couple of years now, though not as a ninja, because of WordPress. In essence, I was downloading nightly builds of WordPress when it was 1.6-alpha (what would become the 2.0.x branch). Now, I am building everything on top of SVN, from plugins to personal projects, to contractor projects and on. Repositories are a commodity and with change control and versioning, it makes it dirt easy to revert when something is broke.
So I took the next logical step personally, and wrote a cron job to automatically svn me to trunk every day. That means I’ll always be running the latest.
Q: What if WordPress introduces a bug that breaks the blog?
A: I can easily revert back to an early revision thanks to SVN.
Q: Why run unstable software?
A: Because this is a biggish blog (Top 2600 in Technorati today, whoo!) and no better way to find bugs and squash them before WordPress 2.2 is launched (in Aprilish) than to run trunk constantly in a big environment. WordPress.com runs trunk as well, so if it’s good enough for them, it’s good enough for me.
Q: Aren’t you worried about hackers?
A: I’ll answer this gently… Not really. I don’t invite them to hack me, but if they do then it’s good exposure on a flaw and we have kick-ass backup support at LogicWorks. So no, not really. The good outweighs the bad here.