Termtter is a twitter client software working on terminal emulators, which is very easy to extend functions

Here is a view of its interface:

Updating your status is as simple as writing u my new status at the program prompt and installing it is just a matter of doing a

sudo gem install termtter

at the terminal.

Termtter will ask you for your twitter username and password the first time it’s run, and it will write them to the ~/.termtter/config file. It would be a lot better if it used OAuth but being opensource it should be easy to add (albeit being a bit of a challenge being a terminal, client application).

The config file is also the place where you can setup and enable various plugins and extensions, e.g. :

You can post the 100th fibonacci number to twitter by (1) uncomment the line “plugin ‘fib’” and reboot termtter and (2) type “fib 100″ on the termtter. http://twitter.com/ujm/status/1330652098 from the readme

I think that “very easy to extend” is an understatement from a rubyist point of view. Writing a plugin is just a matter of creating a ruby file in the ~/.termtter/plugins directory. A plugin can contain new command definitions, status view filters and hooks to take actions on different events (e.g. before or after posting an update). There are a lot of examples in there and here is one i wrote:

It adds a retwit command (with shortcut RT) which just retwits the given update (takes a single argument, the twit ID to be retwitted).

As you can see it’s really easy to personalize Termtter to fit one’s own usage of Twitter and to experiment with it.

I started observing how people usually hate learning and using too many different tools (except possibly for us geeks), this happens because we have limited resources and look for the maximum utility (this happens most at the cross of the business and consumer markets).

Uncertainty also plays a role in forming our decisions as users, where the perceived value of a new application is decreased by the lack of knowledge about how well it can fit the problems that we need to solve.

This has a few consequences: resistance in adopting new tools since it takes a too big effort to learn and preference for generic tools since they are perceived as more flexible and adaptable to our needs.

To overcome this we may reduce the visible part of the application to a level where the user stops noticing while making sure the user can easily reach the value we add. In the end it will all be about finding a way to give increasing returns for the same effort.

One way to follow this path is leveraging the tools that people are already using, integrating into or with them thus giving new ways to use those “old” and generic applications to do new things. Our invisible application will integrate within the flow of information that the user is receiving, it will remove modality from the interactions and augment the context around the documents and data that the users already handle to enrich the interaction with the same old services. Also, an important role will be played by allowing deep adaptation of the interface, whether automatically or via manual customization by the user (for the italian readers, look also at this presentation by Luca Mascaro).

I am using Parallels to be able to do testing of the apps I’m writing on IE (one site I’m working on has more than 1/3rd of users still IE6…) and to be able to recompile and package an old J2EE application using a proprietary framework and builder that works only on Windows :-(

Until upgrading to Parallels 4.0 (which I did yesterday), generating the EAR for said application was taking more than 25 minutes, now it’s just down to less than 5 minutes! The big improvement seem to be in the (shared) filesystem access but also everything else seems snappier and the VM feels lighter on the system.

Overall a highly recommended upgrade to anyone using the product.

The key to reach this flexibility is the API that gives developers the ability to startup a server, configure it, use it and shut it down. There are libraries for many programming languages but I like the way the boto python library makes it really simple do these things (and a lot more).

Here I’ll show how to use boto to start a server instance then how to send a file to the instance and execute a command on the remote server, and finally I’ll show how to terminate the instance.

To use the boto library you’ll need to install it locally (on your computer) and to use the EC2 api you’ll need to import them:

from boto.ec2.connection import EC2Connection

As with  other AWS services you’ll need to pass the access key and the secret access key to the library (in this case when creating a connection). You can get the keys from the Amazon Web Services “Access Identifiers” page. It’s possible to just set two environment variables holding the keys or you can pass them in to the method calls, I’ll assume for this example that the keys are written inside the script and passed to the methods:

AWS_ACCESS_KEY_ID = 'yourkey'
AWS_SECRET_ACCESS_KEY = 'yoursecret'

conn = EC2Connection(AWS_ACCESS_KEY_ID,
AWS_SECRET_ACCESS_KEY)

First step is to make the connection, Once the connection is created we can use the run_instance to start an instance of an EC2 server image. You can think of a server image as a pre-built virtual server that’s idle waiting to be run. There are public images we can choose from (I’ll use the base Linux Fedora for this example), but any user can customize a running instance and build a private image from that ready to be used.

reservation = conn.run_instances('ami-5647a33f',
                               instance_type='m1.small',
                               key_name='mykey')

instance = reservation.instances[0]

while not instance.update() == 'running':
  time.sleep(5)

the run_instances can take various parameters but only the image is required. Here I’m passing in also the instance type (in this case the “Small” instance type) and a key to use. The key to be used should have been previously generated and/or uploaded to EC2 (e.g. using the AWS Management Console).

The run_instances methods returns a reservation object representing the instance(s) startup request. This also holds the list of instances that are going to be started (we may launch more than one instance in a single run_instances call), in this case (since we are launching just one) we take the first one.

Each instance object has an attribute status which returns its current status, to check for the current status we need to call the update method (which itself returns the current status). When the instance is running it is given a public IP and a public dns name, which we may use to connect.

EC2 has a very flexible shared firewall whose rules and permissions may be manipulated via the API, for instance to enable or disable  connecting via SSH. Different security groups may be defined, to partition our instances into different logical sets e.g. web servers versus backend databases, and each group can be assigned different permissions. All the instances are assigned the ‘default’ security group if not otherwise specified.

With a call to the authorize_security_group method we can allow a specific connection for a given group. E.g. with the following call we  allow SSH to any instance in the default group from the specified IP.

conn.authorize_security_group('default',
                ip_protocol='tcp',
                from_port='22',
                to_port='22',
                cidr_ip='%s/32' % our_ip)

with the following call we can revoke the SSH permission

conn.revoke_security_group('default',
                ip_protocol='tcp',
                from_port='22',
                to_port='22',
                cidr_ip='%s/32' % our_ip)

Once the instance is running and the permissions are setup to allow connecting via ssh, we can connect to it and to run a script on the instance we may simply scp the script and then connect via ssh to run it.

When we are done with the work we can stop use the stop method of the instance object to shut it down:

instance.stop()

For a simple, yet complete example here is a script that can be used to run the benchmarks for the redis key-value store on EC2. In the archive, together with the python script there is a shell script which is copied to the server which downloads the redis code, compiles it and runs the benchmarks:

redis-bench-ec2.zip

That’s all!

from datetime import datetime

echo $PATH

If the process succeeds we’ll be able to have a

world where it won’t matter if you’re on Facebook, MySpace or Microsoft Live – where Yahoo’s content is read by Friendfeed, and your MySpace music preferences are matched with friends in Facebook so that you all can coordinate events on Eventful that you heard about on someone’s TypePad blog and was Twittered about on Seesmic and later indexed and searched by Google.

I’ve been able to follow just a bit of the initial presentations on the UStream but Plaxo’s John McCrea has a detailed live blogging post, moreover all the presentations are online at slideshare (plus here are the UStream recorded sessions)

The first thing I find interesting are the results of the Plaxo/Google hybrid OpenID/OAuth experiment. The stunning 92% rate of click through success shows that the open protocols can be made more effective by implementing a better user experience. Moreover it shows that the users, if given a good enough experience, will not fear to follow a path that’s different from the antipattern they have been (mis)educated to use.

The Plaxo/Google process is awesome if you think about the amount of interaction that is taking place within those two clicks

It’s a win-win as this shows how something may be made at the same time

On the downside of this approach is that it will not be easy to scale this beyond the single provider. I hope it doesn’t ends up in a proliferation of single-provider buttons (for somthing that may be implemented with the same undelying technology).

This is a treat without cooperation among the interested parties but looking at the meeting and how the big-cos and many of the smaller players are talking to each other there is hope that it will happen for real.

One critique that I hear a lot is that the way the bigger players are approaching OpenID, basically turning every one of their accounts into an OpenID for their users is not really helping the open web since it’s like every site giving out an email address everybody can send to but just accepting email from their own email addresses. This is true, but here lies also a great opportunity for the smaller players. If you are a startup you should be happy, as what’s happening may mean that you can have a lot more potential users with an easier path to try out your service (got a google account? no need to signup!).
Ideally one’s identity online should not be tied to a specific service, but more likely each user will have one main service which represents his own main “self” online. That will be the main service they use online, the one they are spending more time on. It may be a Google account or a Facebook one or a Myspace identity or their wordpress.com hosted blog, but we can be almost sure that it will not be your shiny new little service.

It’s a great thing that now most of these “main” identities have become portable (thanks to OpenID and Facebook Connect) that is usable elsewhere, just being able to tap into the great number of people that will already have one of the hub-provided identities

You should start right now to plan and execute to adopt OpenID as a consumer, adding also Facebook Connect in the mix as long as they are separate (hopefully they’ll be interoperable in the future).

I don’t want provide a new identity just to be able to tell who you are, thus I, for sure, will try to do this with the services I’m working on.

P.S. I specially like this quote from Chris Messina I read on the ReadWriteWeb:

user authentication is like a credit card. You don’t go to a restaurant because they accept credit cards, you go because they have good food. To take that analogy a step further, it is good that every restaurant lets you pay for your food with any of the major credit card vendors

The real breakthrough is that this will enable a whole sector within our industry to transition to a modern architecture. There are a lot of ISVs which have invested heavily and have a great knowhow in mainframe technologies and those were facing tough times with clients lending towards web services and cloud systems to renew their IT (this is specially true for many small italian software houses working on ERP systems).

With this offering those ISVs will be able to transition current clients to cloud systems and perhaps they will be able to re-engineer and modernize their software one piece at a time as hopefully the Microfocus service will enable new ways to integrate mainframe software and internet services.