Let’s make seeking bliss easier
Let me start by explaining something I want to build (when I find time) called Mailhook. The idea came from building an email service (as opposed to webservice) prototype called Transmutiy that would take images via email and send you back a converted image based on the email address you sent it to. So sending a bunch of 1024×768 jpegs to “800×600animatedgif@transmutify.com” would send you back an 800×600 animated gif image made from your jpegs. That was the original use-case, but take it step further and imagine sending an AVI or even flash movie to “mp4@transmutify.com” to get an mp4 version of your movie back.
In building the Transmutify prototype, and never having worked with receiving emails before, I realized it really sucks getting that to work. Which is unfortunate because it’s a great interface. Who doesn’t know how to send email? So Mailhook would be a place where you register a subdomain that would accept email and then make an HTTP post to a URL you specify when it receives mail (an example of a web hook). This would make accepting emails as easy as it is to accept HTML form submissions.
Things like Mailhook are a good idea and I should get unpaid interns to build them (or maybe lazy web? I tried to get my colleague, Matt, to build Mailhook, but he himself is lazy). The idea can be generalized as email to HTTP. It’s an example of what I call a micro-webservice. These kinds of webservices abstract out tiny, common concerns of larger webservices which can be used to outsource functionality of new webservices. This would a) make it easier to make new webservices, and b) enrich the possibility space of webservices by making certain functionality more accessible.
The best kinds of webservices (most of which wouldn’t be considered micro-webservices because of their inherent complexity) will be those that act as I/O to the real world. Payments gateways are an example of an I/O that gives webservices access to real world currency transactions. Custom clothing sites like Cafepress are another example, if only they exposed a web API. However, even Cafepress would have abstractable concerns, like warehousing and shipping. This would be a webservice that also has some real world process, but imagine a service that you could ship things to with an ID. They would not only store them, but let you automatically ship them out via an API.
Peanut-butterization is a term Adam Smith coined that would be cool if adopted because the idea behind it is very important. It came from PBwiki, a great wiki webservice originally made with existing open source software. JellyBB parodies PBwiki, but is another example of peanut-butterization. Even DevjaVu is a service from peanut-butterized open source software. The idea has been mentioned several times in talking with Adam of “peanut-butterizing” peanut-butterization. Imagine a webservice that would build you a webservice given a piece of open source software. We laugh about it, but we’re only half joking about it. By doing it enough by hand, it’s very likely that, at the very least, some patterns can be identified that tools can be made from to make the process of peanut-butterizing easier.
Why would we want to do that? The same reason peanut-butterization is a good idea in general, and the same reason we need micro-webservices. So that service creators can work at a higher level. Why would we want that? Because then we’d have more time to focus on the user experience and making a great service. We’d also get less hesitence to making new webservices, which means we’d get more of them, which would drive niches, and if factoring in things like web hooks and APIs, we’d get more webservices that would do EXACTLY what we want as users. Which ultimately means that we can then be that much closer to focusing on the problems we really want to work on in life (aka seeking bliss).
Now what I was originally trying to get to was an idea of automated technology development, but this seems like a good stopping point, so I think I’ll save that one for later.