When I last touched on my Twitter badge’s future, I noted that Twitter was giving us roughly six months before they shuttered v1.0 of their API which was all that was keeping my Twitter Statuses JavaScript Badge alive. They actually gave us eight months, but finally completed the API v1 retirement on June 11th 2013 and my Twitter Statuses Badge functionality ceased along with it.

The Twitter Statuses Badge was an interesting project for me, but was in dire need of some modernization which I had not had the time to give it. While I understand the want for consistency, I’m still disappointed in Twitter for their restriction of artistic freedom with the Developer Display Requirements, the other death knell for my badge.

So, today I officially lie my Twitter Statuses Badge to rest and suggest the use of the official Embedded Timelines instead.

In mid-August, Twitter announced there would be big changes coming in v1.1 of their API which they then released at the beginning of September (officially deprecating the v1.0 of their API). Well, three days ago my Twitter Statuses JavaScript Badge stopped working on all my sites and everyone else’s that uses it too.

Back when I first started its development in 2007, there was no official, versioned API and it’s managed to continue working this entire time. Clearly, Twitter decided that with v1.0 of the API deprecated, that anything using older calls than that would no longer need to be supported. So, I’ve updated to the v1.0 API calls and all is working again… for now (more on that in a sec).

Go download v0.7.2 now (the source code is also on GitHub), or you can just change the following line in your HTML:

<script type="text/javascript" src="http://www.twitter.com/statuses/user_timeline/morgant.json?skip_user=true&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

To the following (replacing “morgant” with the appropriate Twitter username for your use, of course):

<script type="text/javascript" src="http://api.twitter.com/1/statuses/user_timeline.json?screen_name=morgant&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

A Few Words on the Future

Now, v0.7.2 of my Twitter Statuses JavaScript Badge only brings us up to v1.0 of the Twitter API which is now deprecated and will be discontinued in roughly six months. Why not go straight to v1.1 of the Twitter API? Well, there are two major changes in v1.1 that would have a major impact on the JavaScript badge: requiring OAuth for all API requests and the display guidelines will become display requirements.

The latter, requiring the JavaScript badge’s display to conform to the specific display requirements, would require some minor CSS changes and is not too big a deal. That said, since the primary goal of the JavaScript badge is to allow customization of the styling, esp. integrating with a site’s theme, it could not enforce that only certain styling rules would be modifiable and so it’d be up to the developer using it to ensure that they too were meeting the requirements. This might be acceptable, but there’s also a chance that Twitter would object.

The former, requiring OAuth authentication for all API requests, is unfortunately a show stopper. OAuth requires registering an application with Twitter (easy) and using secret access tokens as authorization to the API (the problem). The reason this is a problem is that JavaScript runs client-side and can be fully inspected by any user, so the secret access tokens are not very “secret” and could easily be reused by someone else for nefarious purposes.

The OAuth issues could be worked around by implementing the badge server-side in PHP or another language, but then it would not be the same paste-in solution it currently is. I could create a web service that acted as the middle-man, allowing one to create badges that would be populated using a small amount of JavaScript and allowed me to control the majority of the CSS styling with hooks for specific theming, but then you might as well just use the official Twitter Embedded Timelines badges.

So, the future for my Twitter Statuses JavaScript Badge looks bleak. It’s highly likely that this is its last six months, which is too bad as I still had features planned. I’m not going to call it quits yet as I’ve got a number of months to consider my options, but discontinuing it is definitely on the table.

I’ve been playing with NewtonScript a bit in what little spare time I have, hence the previous posts on the subject. The eventual plan, of course, is to put together a few new packages for my MessagePad 2100, maybe even something useful to others, but in the meantime I just want to get comfortable with the language. For that, I’ve found playing with NEWT/0 to be the easiest, but, while the core is there, a number of the built-in functions are still missing.

One such function was Perform(), which allows dynamically sending a message to a frame. I say was because, with Makoto Nukui (NEWT/0’s developer) pointing (and re-pointing) me in the right direction, I was able to implement all the message sending global functions, namely: Apply(), Perform(), PerformIfDefined(), ProtoPerform(), and ProtoPerformIfDefined(). All of which have been merged back to master, so they’re at your disposal if you build newt from the latest source.

No need to go into details on the implementation, the functionality was already there and just needed to be wrapped around, but I did want to discuss usage of Perform(). I won’t cover its variants as they’re called the same way, they just allow silent failures (in the case of *IfDefined()) or different inheritance searching (in the case of Proto*()).

As I mentioned above, Perform() allows you to more dynamically send a message to a frame. For example, let’s take the following frame which has a Test() method:

someFrame := {
	Test: func () begin
		Print("Hello world.\n");
	end
};

Normally, if we wanted to send the someFrame frame a message of Test, we’d do so as follows:

someFrame:Test();

And it would execute the Test method, outputting:

Hello world.

Well, what if you didn’t know until runtime how many arguments you should need to pass along with message you’re sending? That’s where Perform comes in. It takes three arguments: the frame you want to send the message to, a symbol denoting which method should be called, and an array of parameters to send to said method (or nil if not passing any arguments). So, building on our previous example, like so:

Perform(someFrame, 'Test, nil);

Or, if one were passing parameters along with the message:

Perform(someOtherFrame, 'SomeOtherMethod, ["parameter 1", 2]);

Note the use of the quoted constant, 'Test & 'SomeOtherMethod, naming the method to be called. What if you also didn’t know the name of the method until runtime? How can you convert a string to a symbol to pass to Perform()? Fortunately, there’s Intern(), which returns a symbol when passed a string. With that, we can fully dynamically send a message to a frame, as follows:

methodName := "Test";
Perform(someFrame, Intern(methodName), nil);

This is all documented in The NewtonScript Programming Language (PDF; mirrors: UNNA, Newted), but it’s spread out a bit, so figured I’d summarize it all in one place. I’d love to see others start playing with NewtonScript more as well.

Shortly after my recent post of a realpath implementation in bash my friend David Kendal suggested a C implementation would be preferable. I have to admit, it’s far simpler code, it wraps around the actual realpath() so no work to make it functionally equivalent, and it’ll be immensely faster (although I haven’t benchmarked it). See his example implementation. I really can’t agree more.

That said, I do see use for the bash implementation.

Why bash?

Most of my bash scripts are are exercises to keep my bash-fu honed, so this one certainly started that way and did so as a part of tools-osx. While not a modern, object-oriented language, I find bash to be there for me on nearly every platform I use (excluding the obvious like pre-Mac OS X, Newton OS, etc.) without needing to build or install anything else. There are feature differences between versions, but they are minor.

It’s very much in the spirit of UNIX and forces you to use the other command-line tools at your disposal, in conjunction with each other. So, I find it a great way to master more command-line tools and also to become a better command-line user. The more I learn in bash the more I’m able to do efficiently on the command-line, esp. complex tasks. As a server admin, this is immensely helpful. And, the server admin in me is probably why I find it greatly comforting to not have to install or maintain another language and its tools.

It’s a relatively minimalist language and lacks a lot of niceties, but I consider it a bit of a survivalist language at this point. It’s no Perl, Python, or Ruby and it may be frustrating to work with arrays or return anything but integers, but if you can master it you’ll be able to be tossed into any random server and come out alive.

So, Why realpath in bash?

The real benefit for a realpath implementation in bash is the portability without the need to compile for new platforms. Simply copy to the appropriate directory and you’re done. This is ideal for situations where you cannot guarantee a compiler will be available (the use-case for tools-osx) or cannot have a compiler installed (one I commonly encounter in my admin work due to various security requirements, but also one people with shared hosts often run into).

I was also recently contacted by someone who is using my realpath implementation in part of the process for launching a Java app on Linux and Mac OS X, so in this case it’s ideal to keep everything extremely portable with only one codebase and no build process required. Exactly the kind of thing I had in mind.

In Conclusion

So, the bash implementation of realpath has a couple of use-cases, mostly if you’re shooting for no compile process for installation. If you’ve already got a compile process, you’ll probably be better off with the C implementation for performance and to reduce your codebase. If you’re Linux-only, or platforms where you already have readlink available, just use readlink. Naturally, this is all with bash scripting in mind, most higher languages have a built-in realpath function.

I was recently informed of an issue with the in-development version of trash (one of the utilities in tools-osx) that required using an absolute path internally instead of a relative path. In most languages one can just run a path through realpath() to get the absolute path for a relative path, but bash (which trash was developed in) doesn’t have an equivalent. Many people suggest readlink, but it’s generally only included in Linux distributions, so BSD-based operating systems (incl. Mac OS X) are a bit out of luck.

Fortunately, it’s quite easy to emulate using pwd, but there is a bit of extra work that must be done. I found a good, portable example, but it still wasn’t quite up to my standards. I’ve simplified & improved it and the result is as follows (last updated 2012-11-29):

function realpath()
{
	local success=true
	local path="$1"

	# make sure the string isn't empty as that implies something in further logic
	if [ -z "$path" ]; then
		success=false
	else
		# start with the file name (sans the trailing slash)
		path="${path%/}"

		# if we stripped off the trailing slash and were left with nothing, that means we're in the root directory
		if [ -z "$path" ]; then
			path="/"
		fi

		# get the basename of the file (ignoring '.' & '..', because they're really part of the path)
		local file_basename="${path##*/}"
		if [[ ( "$file_basename" = "." ) || ( "$file_basename" = ".." ) ]]; then
			file_basename=""
		fi

		# extracts the directory component of the full path, if it's empty then assume '.' (the current working directory)
		local directory="${path%$file_basename}"
		if [ -z "$directory" ]; then
			directory='.'
		fi

		# attempt to change to the directory
		if ! cd "$directory" &>/dev/null ; then
			success=false
		fi

		if $success; then
			# does the filename exist?
			if [[ ( -n "$file_basename" ) && ( ! -e "$file_basename" ) ]]; then
				success=false
			fi

			# get the absolute path of the current directory & change back to previous directory
			local abs_path="$(pwd -P)"
			cd "-" &>/dev/null

			# Append base filename to absolute path
			if [ "${abs_path}" = "/" ]; then
				abs_path="${abs_path}${file_basename}"
			else
				abs_path="${abs_path}/${file_basename}"
			fi

			# output the absolute path
			echo "$abs_path"
		fi
	fi

	$success
}

Here’s a simple example of its usage:

relative_path="../Shared/"
absolute_path="$(realpath "$relative_path")"
if [ $? -eq 0 ]; then
	echo "absolute_path = $absolute_path"
else
	echo "'$relative_path' does not exist!"
fi

I have also tossed together a realpath tool which wraps around this implementation if you would like to install it for use in multiple scripts/tools. Feel free to download it from the development page or get the source code on GitHub. It’s released under a BSD license.