Monday, October 22, 2007

smart files syncronisation using rsync

I work a lot from home using my laptop. Alas, compiling and testing the application requires a very strong machine like the desktop I have at work. So working effectively from home means syncing files back and forth.
The fastest way to do that seems to be rsync, but running the script is a bit slow since I need to modify it each time according to the directory I'm located at. To help with that I wrote two nice scripts which I named 'up' and 'down', and placed them in the path.
One important fact is that I have the same directory structure in the local and remote machines. I.e. I have the same usernames and place the sources in the same place in both machines.

  • When I type 'up' in the command line the script is syncing to the remote machine the current directory with its subdirectory (recursively).
  • When I type 'down' in the command line the script is syncing from the remote machine to the current directory (recursively).
It is very helpful to have ssh without password (i.e. exchange public keys between machines).

Here are the scripts:
up

#!/bin/sh
# Destination host machine name
DEST="myRemoteMachineName"
# User that rsync will connect as
USER="myUserName"
# excludes file - Contains wildcard patterns of files to exclude.
# i.e., *~, *.bak, etc. One "pattern" per line.
# You must create this file.
EXCLUDES=[full path to file]
HERE=$(pwd)
PARENT=$(dirname $(pwd))
OPTS="-v -u -a --rsh=ssh --exclude-from=$EXCLUDES --stats --delete "
rsync $OPTS $HERE $USER@$DEST:$PARENT

down

#!/bin/sh
# Destination host machine name
DEST="myRemoteMachineName"
# User that rsync will connect as
USER="myUserName"
# excludes file - Contains wildcard patterns of files to exclude.
# i.e., *~, *.bak, etc. One "pattern" per line.
# You must create this file.
EXCLUDES=[full path to file]
HERE=$(pwd)
PARENT=$(dirname $(pwd))
OPTS="-v -u -a --rsh=ssh --exclude-from=$EXCLUDES --stats --delete "
rsync $OPTS $USER@$DEST:$HERE $PARENT


Bugs:
Does not work with whitespaces in the path. Tried replacing them with escape characters (see rsync man pages), bit didn't work.

Wednesday, October 17, 2007

Life is too short to stay at a job where you're not doing the things you want to do, where you're not enjoying yourself

This guy definitely nailed it, I probably couldn't say it better. Not that I didn't enjoy myself in IBM Research, but this is probably the main reason I ended here in LinkedIn.

Oh, by the way, we are also hiring. So if you happen to be a really really good Java developer, let us know :-)

Saturday, October 13, 2007

Extreme Blue 2007

In the last two years I worked at IBM I managed/mentored two Extreme Blue groups. The teams did some great stuff related to the Eclipse Open Healthcare Framework which I was heavily involved with.
Thanks to Brian for sending out this short video clip of an NBC report on Extreme Blue starring my team from Almaden Research Center (I'm not in the video).

Wednesday, October 10, 2007

Announcing the Java Posse LinkedIn Group

Yesterday morning when I biked to work down the Shoreline blvd I happened to be listening to episode #145 of the Jave Posse.
The night before was a bit rainy so was the road itself, so the user experience was damaged a bit. But thanks for the GoF (Gang-Of-Four a.k.a. Tor, Carl, Dick, and Joe) I enjoyed listening to some philosophy (properties in programming languages, and component oriented programming), religion (tabs vs spaces), and other fun stuff.
Nevertheless my mind was a bit districted with a how to test a small LinkedIn Groups feature I just implemented. And then, just when the posse called out names from the IRC room I had an enlightenment: how about creating a Java Posse LinkedIn Group?

Few reasons:

  • Looking at the activity in the Posse newsgroup (and IRC room) its apparent that a community is being created. This group could be a yet another community affiliation mark.
  • A way to publicize the podcast. People how might look at your profiles and think to himself "Lots of techies I know are in this Java Posse group; wonder what’s that all about...".
  • A way for you to publicize yourself: "only real Java masters listen to the Posse" or "Listening to the Java Posse makes you a Java master" (and wearing Nike makes you an athlete...).
  • You could more easily find how is that guy how wrote something about that subject in the Posse newsgroup.
  • I will be able to test the group’s features as a real user :-)
In his excellent post A Group Is Its Own Worst Enemy, Clay Shirky wrote that a good community should have some entrance barriers. I think he got something there, therefore I'll post the invitation URL only in the Posse newsgroup.
Yea, it's easy to get there and find the link, but many people will drop on the way and may only the fit remain. Placing the link on a blog will reduce the efficiency of the group. If that barrier won't be enough, or someone will post the link in his blog, then we'll probably have to kill him and think on other joining barriers.

So please go ahead and join the group...

Tuesday, October 09, 2007

JUNG - Java Universal Network/Graph Framework

Lately I played around with JUNG on an applet, doing visual modeling of networks. Knowing where I work lives a little room for guesses of the type of networks ;-)

Few reasons why I liked JUNG:
* Good generics utilization
* Fantastic plugability of views, model objects, grouping algorithms
* Flexibility and good separation of concerns
* The visualization runs on both desktop apps and applets.

Working with JUNG was a real pleasure, but had lots of drawbacks. First and foremost I have to mention that I used version 2.0 which is still in its beta. It reacted as a beta would react:
* Trowed NPEs when under pressure.
* Had problems with frequent updates to the graph (using the Swing update thread).
* Didn't scale good with dense networks with more then a hundred nodes.
* Very heavy on the CPU.

As a good open source user I know I should report the bugs and suggest patches. Promise I'll do it when I'll get back to it.
The bottom line is that it gave me a bad taste in the mouth about using Applets for intensive graphics and computing applications.

I'll give it a second round when JUNG 2.0 will finalize (anyone know when?), but unfortunately it looks like that in this case Java should stay in the backend and let Flash or similar technology run the browser side.

Creative Commons License This work by Eishay Smith is licensed under a Creative Commons Attribution 3.0 Unported License.