Navarr's Tech Side

So, you think you’ve had a lot of fun with twitter on the web and all those twitter clients you’ve played around with?  What if I told you that you haven’t seen anything yet?  What if I told you that you could use Twitter in a TRUE Command Line Interface with specific commands for interacting with twitter.

Welcome to one of my latest and greatest creations, TwCLI.

TwCLI supports almost everything twitter has to offer, and will soon be expanding to support even more!  TwCLI includes a long list of commands, help information for each command, a theme-able interface (Specify a Pre-Determined theme, import from your twitter profile, or even specify an external CSS file!), Geo-Location, Retweets, and even Contributor Support!

Go ahead, give it a try and tell me what you think!

Apparently I’ve completely broken simpleTAPI somewhere between Build 27 and Build 30.  I thought I had fixed it with Build 29, but it seems that I was mistaken.

In lieu of this, I am putting simpleTAPI on a temporary hiatus.  I will be re-constructing it from scratch (though, probably looking back and using a good bit of the original code).  The next version should have several configurable options, and will hopefully interact with the Twitter API much better than the previous versions.

Build 30 was supposed to return results as an array([“TAPI”] => data, [“result”] => data).  But all I’m getting from it at the moment is “Unable to Authenticate User.”

Those wanting to use simpleTAPI should use Build 27, though you will have to deal with some minor quirks in the way results are returned.  (the TAPI array is simply appended to the results array, making things slightly complicated if you don’t unset($result[“TAPI”]);

What will be simpleTAPI 0.4 should have better error handling, better return data, and better built-in caching.  I’m also hoping to build in support for xAuth and Delegated OAuth, if at all possible.  (Though probably not since simpleTAPI is built upon another OAuth library).

So, I’m asking for any and all feature requests.  Is there something about simpleTAPI you don’t like or want to be improved?  Please, post in the comments below!

A lot of people use my Simple Twitter Feed written in JavaScript (for some reason).  Well, today I pushed out a quick update that should fix all the woes users have given me in the past.

The code should now be valid XHTML strict, and I know longer use innerHTML for each list element.  Instead, I’ve moved from adding the list elements via innerHTML to DOM Manipulation (appendChild).  I’m not sure exactly what the benefits of this are, but I’m sure they exist.

As the previous HTML code seems to have been broken, this may cause some rendering errors for a few websites, but all in all it should work better than it has previously.

I’m not writing out a whole changelog, I’m just going ahead and saying that some changes were made – and hopefully Simple Twitter should work a lot easier for everyone using it.

Something I learned about recently by following the updates being issued to Chrome, is that with today’s release they also pushed out the Webkit Notifications API to Chrome Stable (v4).  Surprisingly, this is actually the first I’ve heard of it’s existence.  I took a look and played around with it a bit, and it is qué cool.

Visit my Sandbox to see the code in action, or continue reading for some code excerpts.

read more »

This is the first post of a new series, looking at some of the odder bugs encountered while developing for the expanding Web, no matter how basic a bug it may be.

Thanks to twitter user @paperfairy, a bug was discovered on my Command Line Twitter Client, TwCLI.

For some reason, when submitting a command in Chrome for Linux, the page would simply refresh, and the command would never be sent.  At first, I had no possible way to track down this bug.  I didn’t have a linux box (with a GUI, anyway) so I simply told him that it was unfortunate, but it’d have to stay a bug.  Until a recent post on lifehacker brought my attention to Portable Ubuntu. I immediately installed it, opened up the Chrome website in Firiefox, installed Chrome Beta, and headed over to TwCLI to see what was amiss.

Of course, it was a single line in a detection script to send Geo-Data to Twitter (as long as the user approved it, of course):

else if(google.gears) {

This single line was throwing an exception I hadn’t encountered in other browsers – Google wasn’t defined.  Oddly, I thought it would handle that properly, since google wasn’t defined, it would just skip over it, but instead it threw an error and halted all further javascript code.

The fix was simpler than tracking down the bug, I simply had to add this to the start of the javascript code:

try{ if(!google) { google = 0; } } catch(err) { google = 0; }

And voila, I had both a check for google, and a catch if it decided to throw errors while checking for it.

Whether this is a Chrome bug or not, I don’t know – I simply don’t know enough about JavaScript in order to say so either way.  But, are undefined variables supposed to throw errors, or are they simply supposed to return false?

Usage:

• Call createLightbox(); to create the actual lightbox element (does not display anything).
• Call fillLightbox(string content) to fill the lightbox with RAW HTMLor

  Call appendLightbox(element childElement) to append a DOM Node directly into the lightbox.

• Call setLightboxSize(int width, int height, null, string unit) to set the width and height of the lightbox.  Unit will default to pixels “px” if not specified.
• Call showLightbox() to actually display the lightbox to the user.
• Call boolean lightboxVisible() to determine if the lightbox is still visible or not.
• Call hideLightbox() to remove the lightbox from view.
• Call cleanLightbox() to delete all content inside the lightbox container.

I pushed the 子猫ちゃん Google Voice OMS service’s code to github, so you can now download it – albeit, to make it work it’ll take a lot of hacking and a lot more editing.

Either way, I’ve gotten no donations and no offers for free SSL hosting, so it looks like this project just will not be seeing the light of day.  It’s a shame, I worked a long time to make it work, and it’s obviously something a lot of business professionals would be able to find a use for.

Oh well, you can find the project on github.

Remember to abide by the Usage License!

This might mainly be a “call-out” to Dave Winer, since he is continually attempting to push RSS for all sorts of data that should be inherited around the web – although, he has stated before that he likes JSON – I think – My memory is not so good, even my girlfriend has been complaining about it.

Either way, I’m just going to take a small amount of time here to list why I no longer like XML and RSS for portable data.

It’s too low-level.

XML and RSS are a markup language, of course.  It’s very low-level code, and is generally a pain to parse in any language.  Which is why I prefer JSON.

It’s high-level code.

JSON is a very simple object – It’s basically an array of data.  Here is some XML vs. JSON:

XML

<data>

    <user id="876232">

        <name>User Name</name>

        <screenName>User</screenName>

    </user>

</data>

JSON

"user":["id":876232,"name":"User Name","screenName":"User"]

Even though you can get similar results by making id its own tag in the XML, its still difficult to parse.  Where as with JSON, the data is already formatted and easily accessible.  Especially in my favorite language, PHP.

// For Json

    $json = json_decode($data,TRUE); // Decodes JSON and makes it a true array

    $id = $json["user"]["id"];

    $name = $json["user"]["name"];

// For XML

    $xml = new SimpleXML($data);

    $id = $xml->user["id"];

    $name = $xml->user->name;

The two are very close, but in the end JSON is more simplistic – because its such a high-level language.

I pushed Build 13 today.  This build adds the recent addition of descriptions to a user’s list.

This change breaks:

• TwitterAPI::lists_create and
• TwitterAPI::lists_update

The new profiles for these commands are as follows:

TwitterAPI::lists_create( str $name [, str $description = NULL [, bool $privacy = TWITTER_PRIVACY_PUBLIC ] ] )

TwitterAPI::lists_update( str $name [, str $new_name = NULL [, str $description = NULL [, bool $privacy = NULL ] ] ] )

If you’ve been watching this blog, you’ll notice I skipped Build 11 – It was small, and was trumped by its quick replacement – Build 12.  Builds 11 and 12 fixed five previous known issues, while build 12 fixed a non-issue with build 11.  Fixes listed below:

• The following now work with all users:
  • Twitter::get_sn_from_id()
  • Twitter::get_name_from_id()
  • Twitter::get_id_from_sn()
  • TWML::name()
  • TWML::profile_pic()
• Addition of User Cache commands for use by TWML and the get_x_from_y() commands.

As always, the most recent build is available at github.