Coining Some New Terms - "Twarkov" & "Mashout"

OK - So I have just got in from work and forced myself to get on Live Writer since I knew damn well if I didn't, another day would go by without a blog post - and I actually have a few things stacked up that I want to cover.

So, here is the first - I would like to coin two new terms:

"Twarkov"

OK, yes, this one is a little bit of stupidity and silliness, but there is method behind my madness, so hear me out :P

Recently there seems to have been a surge of spam bot's on Twitter. Now, this confuses me, because I really don't know what type of content they could be harvesting, or what they could hope to obtain by spamming on there. Since its obvious they are bot's, people will block them straight away, so they are not going to get any link-clicks. I have a theory in that maybe the spam companies are getting smarter and going to start targeting spam based on the topics of interest that you discuss (similar to Google Adsense).

So, "why 'Twarkov'" you ask? Well, take a look at my all time favourite tweet from one a Twarkov. The text is kind of gibberish, but actually does make a small amount of sense, this is because the text is generated by a Markov chain. Which basically is a mathematical formula that is applied to common words to have a educated guess at what the next word is going to be. This is why a large number of the words do pair reasonably well. This is how some spam manages to get through your filters, because it can be made to look like a genuine email.

So, there you have it - Twarkov - A twitter spam bot that uses a Markov chain. :)

If the funny text that is produced amuses you, be sure to check out Garkov - Garfield comic strips with a Markov sequence placed in the speech bubbles. Enjoy :)

"Mashout"

Now this one is actually aimed at being less silly and something I intend to actually run through as project at some point. So, what is "Mashout"? For those of you not into software, there is a lot of "Mashup" websites and applications springing up all over the place. A lot of this is due to the much more open, service-orientated applications that are on the web now. These expose an API and allow developers to "tap in" to the service they provide, and use the resultant data how they wish. Now you can have applications that tap into one or several services, which can actually produce a really rich feature set, on relatively little work on developer. An excellent example of not reinventing the wheel and promoting code re-use.

As you probably guessed, "Mashout" ties in with "Mashup". There is an inherent problem with "Mashups" - you are very reliant on the service you are utilising. The most obvious demonstration of this at the moment is probably Twitter. There are many users on the website and many more that use custom client applications (such as Twhirl) to use Twitter's service. Recently Twitter has had real major problems with downtime, for the most part, there isn't a day that goes by without there being a small amount of downtime. This has been both frustrating for Twitter users, and most likely their staff (I think the only one that has done well out of the outages is the "FailWhale" which has now somewhat of it's own fan club). Obviously, if the service goes down, everything goes down. No client applications can use a service that it's cant get a response from.

This got me thinking, "how can we get over this?". I think this is going to become much more of a problem as the "Mashup" applications continue to grow. Those that provide these services are going to become under increased stress on their systems due to the sheer amount of requests they may be receiving. Yes, they can improve their systems, but this could cost a lot of money and these funds may simply not be available (this could especially be the case for small start ups). And I think we, as software developers shouldn't necessarily put all the weight on their shoulders, they are giving us the service for free after all.

And the conclusion I came to, was to "Mashout" - Utilise the service, but instead of relying on a single point of contact between the client and the service provider, you provide your own layer to handle the data transfer more efficiently. You extend the service to make it more distributed within your application context.

I see it this way, if we all hate the way services can be slow, buggy, featureless, why the hell aren't we thinking up ways to get around it? We are software developers, get hacking!

I do have other ideas I would like to cover with regards to this subject, but I will save that for another post. I just wanted to get my thoughts out there and see what people think.

Comment please!

And remember - no one can compete with the randomly placed hair clip :D

Share:  digg it! |  del.icio.us |  Live |  Technorati |  Facebook