The Agile Micro ISV Blog

Image via CrunchBase

I’ve been on the scout for a nice way to capture, prioritise, schedule and track tasks. My requirements were fairly simple –

• Be able to capture tasks quickly
• Be able to prioritise tasks
• Be able to schedule tasks
• Be able to track tasks
• Must integrate with my Blackberry.

I had a look at a few solutions, but the one that really impressed
me was Remember The Milk. Let’s skip past the hyperbole and dig
straight down to why I like it.

Remember
The Milk (RTM) allows you to create as many lists as you like. I have a
quite minimalist approach to lists, but in your Task view, they are
simply tabs:

If tags are more your thing, you can add any number of tags to a task, and there’s a helpful tag cloud for familiar navigation.

Task details are easily set:

RTM integrates with GMail (including Google Apps). This wasn’t a
requirement by any means, but considering that it’s one of my most
visited web pages, it was a most welcome addition.

Tasks are easily prioritised and colour coded.

I
would heartily recommend that you spend a few minutes to become
familiar with the keyboard shortcuts, they will dramatically improve
the speed with which you can use the site.

The RTM web interface
is good and I use it every day, but it’s strength is in its
integration. It integrates with my Blackberry (yay!), Windows Mobile, GMail, Google calendar, iGoogle, iPhone/iPod Touch, standard mobiles and Twitter. You can receive reminders via email, SMS, and instant messenger (AIM,
Gadu-Gadu, Google Talk, ICQ, Jabber, MSN, Skype and Yahoo! are all
supported). In other words, you would be hard pressed to not be on top of your task list.

Some
of the integrated services are available only to pro account holders
(of which I am one) – but considering the price tag – $25/year – I
would say benefit to cost ratio is sky high, so why not sign up for a free account and give it a whirl.

What do you use for task management?

Image via Wikipedia

The third and final part of this mini series (trilogy?) is on
reverse tunnelling, or remote forwarding. Let me give you an example of
when this might be useful:

Let’s say you’re on a client’s site. Let’s say your client has a
build server that’s only accessible from the internal network. Let’s
also say that your client is a humungous corporate blob, with 8
signatures and 6 weeks lead time in getting VPN
set up for you. Or maybe if you’re a consultant they won’t let you have
VPN at all. Mentioning no names…. – You need to be able to kick
off a build at some point over a weekend. And since the client’s site
is a gazillion miles from your home, you’d rather not hang around.

No problem. SSH is here to save the day. Our hypothetical build
server sits on 192.168.1.123 on the client’s internal network. It is
also set up for access via Remote Desktop. While you’re still in the office, we establish a session thus:

putty username@mydomain.com -R 9999:192.168.1.123:3389

This is telling the sshd daemon on your home server to bind to port
9999 and listen for incoming connections. Any incoming connections are
forwarded through the tunnel, to port 3389 on 192.168.1.123 on your clients network.

My home server runs at 192.168.1.101 on my network. So when I’m at
home, if I want to connect to my client’s build machine, I instruct my
remote desktop to connect to 192.168.1.101:9999 and as if by magic, I’m
now on the build machine. Awesome.

SSH is a really awesome workhorse, and if you’re a web worker,
consultant, micro ISV etc I really recommend spending a few moments to
get to grips with it.

Image via Wikipedia

OK, so last time we looked at how to tunnel your web traffic over
SSH to increase security, privacy, network restrictions etc. Today,
we’ll look at how to use port forwarding to access servers that are ordinarily available on the internal network.

Subversion Over SSH
As an example, I’ll show you how I access my internal network’s Subversion server. Here’s my set up:

• Externally, I have MyDomain.com which resolves to my home IP.
• On the internal network, my Ubuntu server has the address 192.168.1.101.
• The server runs an OpenSSH server and the Subversion svnserve daemon.
• The router forwards incoming connections on port 22 on to my server.

Setting up the tunnel, we do the following:

putty -L 3690:localhost:3690 username@MyDomain.com

Log in as usual. This time, the SSH tunnel
has been set up such that any connections to 127.0.0.1 on port 3690
will be tunnelled to port 3690 on the server. Which, handily, is the
default port used by the svnserve daemon.

And to get hold of some part of the remote repository, we just do:

svn co svn://127.0.0.1:3690/MyRepo

And hey presto, tunnelled access to your internal SVN server. It’s
always puzzled me why the good SVN folks suggest their weird svn+ssh
hack, which launches an svnserve instance in user space, potentially
causing file locking problems and requires user access to the svn
database files.

This technique can be applied to any internal server, whether web, database, remote desktop etc.

Next time we’ll look at reverse tunnels. Very cool.