Have You Read It Yet?

Often times, when interacting with my friends and acquaintances on a day-to-day basis, I find myself asking them "Have you seen that [post I shared/post I wrote]?" Unfortunately, this data must be obtained and is a quite obvious sign of trying to gather reach data from the audience. This is problematic because responses can be skewed and do not give that much insight.

An idea I've been thinking a lot about is social media. Often times, there's an interest in seeing which users have seen which content, when, where, and such things as that. Many people--not just corporations but actual users--are interested in understanding who their posts reaches, what kinds of feedback it gets, and such things. This data can be ascertained by measuring the amount of time that a user spends viewing a certain post. A system can be designed to determine whether or not content is visible and then determine the user's response.

Unfortunately, measuring the user's response is difficult. Ideally, it would be as simple as measuring whether or not they interact with the content, however people are becoming increasingly lazy and such behavior is difficult to measure. For example, Google+, Facebook, and Twitter all aggregate content into a centralized page (called the "news feed" or "timeline") to display to the user, and the user generally does not click anything. Therefore, the data needs to measure not only interactions with content but times that a post has been viewed.

Using statistical analysis algorithms which I have neither formed nor found as of yet, the user's post response times can be measured. There are users who simply scroll through their feed until they find something interesting, and it is important to measure which posts they scroll past as well as what causes them to stop. If a post is visible, a timer would be started for that post, and as soon as it became invisible or was accessed, that timer would be stopped. If the user clicked on the content, then that would count as interest in that content and would count as a reach. If the user read through the content (i.e. if it were a text post), then the reach of a post could be measured through post view time.

I plan to toy around with these algorithms soon. Timing post content seems to be the most difficult thing and differentiating attention also. The main problem will be aggregating and processing it in a timely manner and without considerable lag. We'll see where this idea goes.

Functionality vs. Fastness

A question that language developers have faced for a long time is whether or not to make their language the "does-it-all" or the "does-it-fast" of languages.

On one end of the spectrum are the low-level languages. Think C/C++--the ones with low functionality and high fastness. On the other end is all of the "bloated" languages. Think PHP, Java 6--the ones with high functionality and low fastness. I often find myself swapping between languages on both ends of this spectrum. Up until recently, there hasn't really been a language I've known of that treats the world with both sides of the picture: high functionality and high fastness.

Enter Ruby. Ruby calls itself "a programmer's best friend" for a very good reason. It's insanely functional (one can write a web server gem, odd as it may look, in 6 lines of Ruby code), and also insanely fast. It powers many of the world's famous social networks, and for good reason.

For me, Ruby makes the most sense. Everything I want to do can be done in Ruby in some way. Writing a module to use in other projects is very easy, and then sharing it with the world is even easier. It's the kind of language that encourages expansion; over 71,000 "gems" have been published. From things like cryptography to things like the well-known Rails framework, Ruby plays across the entire gamut.

Things like classes and such are hard to find in the "fast" languages, but come naturally in the "functional" languages. Ruby is what many call "purely" object-oriented; practically everything is represented as an object, and some interesting things come of this behavior. Some projects can be written containing extensions of existing objects, and some major things can be done using one-line changes.

Sure there's still a trade-off between functionality when one uses Ruby (it isn't as fast as some of its counterparts, but it's fast and getting faster), but it's still got much of the "best of both worlds" effect going on.

I'd suggest that you try Ruby if you haven't already. It's interesting to see what has been done and what will continue to happen. Read more, if you're interested. I think it's the perfect combination of both functionality and speed, and is built sanely.