Category: Technology

Melative Tweets

Posted by - March 14, 10

Took a small portion of time today to enable a Twitter bridge (What the hell is that..?) for Melative users while hanging out in the anisphere room.

Sadly, twitter does not enabled source hyperloading overloading, so it didn’t go so well when trying to insert additional information about whatever album, book, manga, anime, tv, film, drama, vn, video game a user might scrobble with ActionStatus. This is what it should look like, but instead updates report ‘from melative’ (boring!).

While Ping.fm and Friendfeed API access has been enabled since last summer, someone brought it to my attention that posting directly to Twitter is more attractive than proxying through Ping. So while I have no intention of using whatever it is I just coded, I’m content with added functionality for users.

More info on the blog.

More…

App Basics

Posted by - March 11, 10

Some might be confused about this stuff.

I’ve done my glancing at various app platforms in order to find a good candidate for building a reasonable MediaStatus1 application. So here’s the low-down on some of the most popular candidates.

Adobe Air 2

There are issue with Air, for one, it recklessly consumes resources, but more importantly, lacks any proper method of installation on 64-bit linux platforms. Air 2 has a few interesting feature upgrades, but it’s merely moving closer to being a native app platform. Performance-wise, I’ve seen hints of lower memory usage, but from the numbers I came across in November 09, we’re looking at 5% lower memory consumption. Make of that what you will.

XULRunner

Xulrunner is what runs Mozilla’s Firefox web-browser, and has recently had javascript engine improvements, but still lags behind Chrome’s V8 and Webkit’s SquirrelFish. Xulrunner is very easy to create apps in, but can be sluggish, is non-native, but most crucially, it requires developers to package their own installers. Memory consumption is decent for most applications, and typically 20-30% less than the same functionality in Air.

Appcelerator

Appcelerator’s Titanium platform is great in concept, but after numerous tries with one of the 0.9 releases, I could not get the developer to work properly. I believe this came down to the 64-bit nature of my system. The attractiveness of Titanium is the ability to build native and cross-compatible applications, with the ease of Air or Xulrunner.

Python+Qt4

Native, efficient, mature, full of features, and looks really good. The disadvantage of writing in PyQT4 is that it is more involved than simply stringing together some html+css+javascript. Python is real is a nice language, but getting to know GUI programming is the whole reason why XUL and Air exist. Biggest benefits include native, cross-system compatibility and with Qt4, GUI’s are very good on memory (~10MB for a simple app). Would love if Gwibber was built in Qt4, but that’s not likely to happen.

Hopefully this micro-primer helped point out why one may or may not opt to use an application built on one of these platforms. (longer than expected)

Notes

  • 1 - MediaStatus is a module-based service which allows detection of what a user is watching, listening, viewing, playing, etc. I use it for scrobbling pretty much any medium on Melative’s Lime engine.

Show of Hands

Posted by - March 4, 10

Who is using XMPP?*

After searching around, and even toying with OpenFire, I’ve figured out where the open MUC (Multi-User Chat) servers reside, and created an open room, bloggers@conference.neko.im.

What does this enable?

For users with a GTalk or Jabber account on any other server, the room is open and accessible. Considering how many anibloggers have google accounts because of Reader, well I’m sure there are a lot of bloggers with XMPP, so why not use it?

How does this differ from IRC?

Most users connect to their IM by default right? IRC is becoming less popular for ‘general chat’ (non-collaborative chat), and I don’t think that’s a bad thing. As I was chatting with Shance, one of the issue I don’t like about IRC is having to connect to multiple servers with the client, and XMPP MUC, while innately part of YOUR instant message service, gets rid of these implicit connection.

How does it work?

Any XMPP account will work (except Facebook w), and if you want to directly join a chat, a decent multi-chat client; I’m using Pidgin. Once you’re signed on, find the control which says something like, ‘Join Chat’ and fill in the info.

For those using the Google web client, you’ll need a friend to invite you into rooms, so be friendly friends and invite! Also, these open rooms differ than native Google multi-chats in that pretty much anyone can join, and you know I love that kind of thing.

So, anibloggers. Who is using GTalk/Jabber/XMPP somewhere on the web? Come party chat, or make an open room of your own…. they’re all accessible from here on out and unmoderated if configured as such (of course I chose unmoderated rooms).

Cheers.

Notes

*Yes, Google Talk is XMPP. XMPP is the Email of instant messaging; it doesn’t matter what server you’re on.

Getting to Know Buzz

Posted by - February 12, 10

By now, most of us have heard about Google’s newest integration, Buzz, but perhaps one of the main questions that comes with the service is, “what do I need to know about Buzz?”

Answer: nothing.

But just to show the reader there’s nothing they need to know, I’ll go ahead and point out a few items of interest anyway. False disclaimer: this information may be useless.

What does Buzz do?

The first realization people might see is that Buzz sits in the Gmail and basically emails itself over and over when you get Buzzed; it’s very vain, I know. With some simple email filters, this vanity goes away, but the problem still remains, “why are all my email buddies spamming this wall thing?”

This is normal, and the experienced FriendFeed user may find themselves right at home. Buzz, first and foremost, connects things. It connects email identities and it connects the generated data associated with those identities. In short, it allows a user to share their activities from various services with their friends and followers, and allows those friends and followers to discuss or comment if they like.

It’s a simple concept and a high-level abstraction with broad implications. Email identity-based “social network.” That’s enough pointlessness for this section. Moving on.

Buzz for the Google Readerer

Google Reader is a pretty popular thing around this community, especially shared items. Buzz connected with Google Reader works in similar fashion to shared items (they are shared items after all), so even with the different appearance, reading and conversation occur like native Reader shares. See nothing to know. :)

Here are a few interesting, but still highly unnecessary points about Buzz shares:

Muting - Shared items can now be muted. If you don’t like the discussion of a share and don’t want to see it popup as unread stuff, mute it.

Public link - Shares now have a public permalink which shows both the share, and the comment thread. (I know that will please zaitcev a little)…. but really who needs public links?

Replying - Although I’ve not tested it with shared items, users may comment on Buzz updates without any relation to the user. For the most part, you can take part in any thread so long as it’s visible. See how I commented here, no prior relation to the user.

All this new-born suck is okay, because shared items can still be interfaced within Reader. So if you live in a world which doesn’t change, you can still keep it real.

Buzz at the Core

I’ll just go even more out of the way and briefly touch on more unimportant aspects of the concept at hand, the protocols (why they don’t matter can be read here). While there are others specs involved, they are pretty much for structuring data, so here are the big four:

Atom - Most of us are familiar with this, as it’s a feed format for which we can syndicate information. It’s a lot like RSS, but created specifically for this feed stuff. Why’s it special? Simple, it’s extensible (xml is extensible by definition); other unnecessary information can be crammed inside it without any worries.

Bottom line: this one goes to infinity.

PuSH - PuSH is a sexy term, short for pubsubhubbub, aka totally unimportant, but still sexy. It’s a silly spec that allows those Atom things to push updates in real-time to subscribers across open hubs. So long as it’s structured like a feed, PuSH will sex it up.

Bottom line: if polling is a wienerfest, PuSH is definitely a sexy party.

WebFinger - This one is just keepin’ it nasty with the terminology. In the old days, you could straight finger users to find out cool information and stalk them if you like, but now with the web and all… WebFinger is a designed method for hardcore stalking by identities that look a lot like email addresses. Data such as name, bio, a picture, and other services profiles can be attached to an email id with WebFinger.

Bottom line: what’s your position on stalking?

Salmon - As we may know, salmon swim upstream, which I suppose is how this one came to be. It looks a lot like Atom (it is Atom) but has some magic stuff for checking that a “response” is legit. Yes, this is about responses, comments, replies, discussions, threads, conversation… uselessness. It can be considered the Internet’s @reply. With it, one can pretty much @reply anything with a URL…. kinda like how some dogs will hump anything.

Bottom line: conversation is overrated.

Conclusion

If you like uncouth information that really “gets around,” Buzz might be attractive; sometimes it’s fun that way…. yea… Well, hopefully it’s clear why there isn’t anything needed to know about Buzz, and we should all feel very relieved we can continue living in yesterday.

Cheers.