[logback-dev] Twitter Appender?
jhuxhorn at googlemail.com
Wed Aug 5 13:48:32 CEST 2009
On 05.08.2009, at 12:03, Ceki Gulcu wrote:
> Hi Joern,
> TwitterAppender does make sense.
> As a use case, imagine an application problem represented by a logging
> event of level ERROR. The logging event is sent to TwitterAppender
> which tweets (posts a tweeter message) under the account of Alice, a
> dedicated (non-human) tweeter user. Relevant system administrators,
> followers of Alice, would see her tweets and take whatever necessary
> steps are required to respond to the error message. They could do so
> using a tweeter client on a smart phone, for example "tweetie" .
Best of all, there's another application for the iPhone called Boxcar
 that pushes @replies, meaning that a message box pops up on the
phone and an (optional) sound (or vibration if muted) is played when a
reply is received.
So it would probably make sense to send those messages as @replies to
users listed in the appender. This would reduce the number of
available characters, though.
> You could prevent flooding by limiting the number of tweets per time
> frame, say at most once an hour. I actually have code lying somewhere
> which does this using a sophisticated algorithm. Consider flooding
> as a solved problem.
> Evaluators, in particular JaninoEvalurators, could be used to filter
> out certain messages from triggering tweets. Tweets of confidential
> log messages could be avoided assuming the said log messaged contained
> a special marker, say CONFIDENTIAL.
Another way that I forgot would be a twitter account with a private
timeline. Those are not available for searching and can only @reply to
people that are following it. Following must be accepted by the account.
I think this would be sufficient for most cases but something like a
CONFIDENTIAL marker does also make a lot of sense. This would simply
be configured "around" the appender, right?
> The contents of the tweets could be formatted using a PatternLayout
> similar to the way SMTPAppender formats the subject of the outgoing
> email message.
This sounds very good. The only problem I see is that the message
would have a variable length, i.e. 140-username.length()-2, in case of
@replies. Those are much more useful than just a status-update,
though, due to the mentioned push-functionality and special sounds
played by desktop applications.
> How about building a prototype of TweeterAppender?
I could do that but I'm pretty occupied at the moment.
Twitter4J is dead-simple, though.
The dependency is
And sending a status update is done like this:
Twitter twitter = new Twitter(twitterID,twitterPassword);
Status status = twitter.updateStatus(latestStatus);
System.out.println("Successfully updated the status to [" +
status.getText() + "].");
The twitter instance would only be created once and is thread-safe.
I think all that would be needed by a TwitterAppender would by
String users; // ,-seperated list of twitter usernames to use for
List<String> userList; // users parsed from users-variable after
setUsers has been called
The only problem I see is the fact that Twitter does not allow you to
update the status to the same text.
If the appender would try to append "A message" twice it would only be
appendet to the timeline once.
The easiest way to circumvent this would probably be an initial
message like "<context name> is about to tweet a new message:" before
sending the actual message of the event.
>  http://www.atebits.com/tweetie-iphone/
> Joern Huxhorn wrote:
>> Hi guys,
>> I'm using Twitter4J on another small project and I was wondering if
>> a TwitterAppender would make sense.
>> I'd obviously only do something in case of an error to prevent too
>> much tweets followed by a ban of the user.
>> I would have the benefit (at least foe ppl like me that get tweets
>> pushed to their phone ;)) that I would get informed immediately if
>> something really bad happens.
>> I'm just brainstorming here but I'd like to hear other ppls
>> opinions on the case.
>> The Appender would have a dedicated Twitter user. Twitter user and
>> password would be set in the config.
>> Additionally, a list of Twitter usernames would be provided.
>> Those would receive a reply (or a DM?) in case of an error.
>> Some questions that jump to my mind:
>> What should the actual message contain? We only have 140-
>> username.length()-2 characters.
>> Messages shouldn't contain anything confidential...
>> Messages must not be the same all the time. They need to differ,
>> otherwise they will be ignored by Twitter.
>> How should flooding be prevented if the app keeps producing errors
>> (this would ban the twitter user, otherwise)
>> Ideas, Suggestions, Bashing? ;)
More information about the logback-dev