Comments for eventually consistent

Comment on Rails MemCacheStore Fu by colin

colin — Thu, 02 Jul 2009 13:58:42 +0000

@chris, I haven’t used it for session storage but it should just work. I did not try it with Passenger either.

As for a vendored version of the memcache-client gem, it should also just work. You can verify in script/console if the correct client has been installed using the following:

>> MemCache::VERSION
=> “1.7.4″

>> RAILS_CACHE.instance_variable_get(”@data”).class::VERSION
=> “1.7.4″

Colin.

Comment on Rails MemCacheStore Fu by chris

chris — Thu, 02 Jul 2009 00:28:25 +0000

Also, have you tried this with a vendored version of the memcache-client gem?

Thanks.

Comment on Rails MemCacheStore Fu by chris

chris — Wed, 01 Jul 2009 23:43:14 +0000

Have you set this up for session storage?

Also, have you set this up with passenger (e.g. PhusionPassenger.on_event(:starting_worker_process))?

Thanks.

Comment on The next spam wave will come from Twitter real time search by darby

darby — Sat, 23 May 2009 02:59:18 +0000

good post Colin and fully agree. I have noticed, at least on bit.ly is the following message on a few links that I have clicked on,

“”Warning – this site has been flagged by SURBL and may contain unsolicited content.

The content of this web page appears to contain spam, or links to unsolicited or undesired sites.”"

This is definitely a start, however, I do think that if Twitter really wants to gain mainstream, it will have to do some self-checking prior to adding links to tweets or restrict only to URL shortening services that screen links.

Comment on The next spam wave will come from Twitter real time search by colin

colin — Fri, 24 Apr 2009 17:58:03 +0000

url shortening is one issue but not the only issue. I thinks that if url shortning services would do a first pass of spam detection (and having a tinyurl that encodes another tinyurl is easy to deal with) they could provide a certain trust level that their tinyurls are not pointing to spam. For example, if bit.ly would run some url spam filtering, then we could “trust” bit.ly urls not to provide spam and more easily follow them.

On the other hand, I really think Twitter won’t have a choice and come up with spam detection in their tweet stream because they can’t rely on tinyurl services and nothing prevents inserting any url in a tweet. A url can very well not be shortened, not be too funky and still be a spam link.

Comment on The next spam wave will come from Twitter real time search by Jerome Paradis

Jerome Paradis — Fri, 24 Apr 2009 17:16:50 +0000

I agree with Quikredfox.
Twitter clients must run reverse-shortening api calls to show what we’re about to click on. But, if they auto-expand them, shortening services with stats will lose some features. An hover link could work.
However, it’s always hard to fight against spammers. For example, what if the shortened link is another shortened link? Should the client block the link or continue to auto-expand the link infinitely? In any case, spammers could find other ways to obfuscate their links. No easy solution.

Comment on The next spam wave will come from Twitter real time search by Dmitriy

Dmitriy — Fri, 24 Apr 2009 14:51:24 +0000

Your post makes a lot of sense. We will have this problem for as long as decision on relevance is made on the client (based on keywords or hashtags) as opposed to on the server (based on some deeper AI). My post on the subject – http://somic.org/2009/03/18/the-ultimate-twitter/.

Comment on The next spam wave will come from Twitter real time search by Quickredfox

Quickredfox — Fri, 24 Apr 2009 14:31:26 +0000

I’ve read this somewhere at one point in the begining of the url shortening wave, but cant remember the source…

It was about how url shortening services should (as in must) have an API endpoint to give the expanded version of the link and how twitter/rt search clients should (as in must) use that functionality when displaying received notices.

I dont know about the “karma” idea but it seems a good starting point for a community brainstorm on this.

Comment on Compiling Sphinx on OSX Leopard by Martin Dufort

Martin Dufort — Thu, 08 Jan 2009 13:55:42 +0000

Colin: You will encounter the same type of error if you compile the MySQL Native GEM so beware.
Welcome to the Mac.

Comment on Apple’s iPhone AppStore model fails with Internet applications and platforms. by Martin Dufort

Martin Dufort — Mon, 08 Dec 2008 20:58:47 +0000

I think it is important to note that all the other Twitter Clients I have on my iPhone (Tweetie, Twinkle, Twitterific) do not suffer from that API change. Not sure if they are all using the JSON or the XML API however.

So while I agree that the Apple approval process for updated applications needs to be streamlined, and they have made some progress on that front, what I call defensive programming for malformed values must also be taken into account.