I personally think for this purpose cygwin is overkill and robocopy is slow and not very intuitive to use. With this bias in mind I was happy to stumble upon this article on installing a minimal rsync/ssh package on Windows. I must try this package out next opportunity!
Monday, November 19, 2007
Minimial rsync/ssh for Windows
Every now and again I'm required to synchronize files between Windows and UNIX, usually a Windows desktop and UNIX server. Some of the commons tools for this task include a Samba Samba / robocopy combination, or installing the UNIX-like cygwin tools to use rsync/scp.
I personally think for this purpose cygwin is overkill and robocopy is slow and not very intuitive to use. With this bias in mind I was happy to stumble upon this article on installing a minimal rsync/ssh package on Windows. I must try this package out next opportunity!
I personally think for this purpose cygwin is overkill and robocopy is slow and not very intuitive to use. With this bias in mind I was happy to stumble upon this article on installing a minimal rsync/ssh package on Windows. I must try this package out next opportunity!
RedHat buys then open sources AMQP implementation
How did I miss this event?
Previously I've blogged about Advanced Message Queue Protocol (AMQP), an effort by JPMorgan to commoditize messaging and break the back (i.e. save on the hugely expensive licensing costs) of the messaging behemoths Tibco and IBM.
According to this article RedHat bought an AMQP implementation from JPMorgan, improved it, then gave the implementation to the Apache Foundation as the QPid project. Currently there is a Java and C++ broker with clients in C++, Java (JMS), Ruby, Pyhton and C# for .NET.
Red Hat has the ambitious goal of enabling a server to process 1 million messages per second.
I guess JP didn't have an interest in maintaining the AMQP implementation, but RedHat are not exactly cheap when it comes to maintenance fees (but so far cheaper than Tibco and IBM).
Update: Microsoft have joined the AMQP working group!
Previously I've blogged about Advanced Message Queue Protocol (AMQP), an effort by JPMorgan to commoditize messaging and break the back (i.e. save on the hugely expensive licensing costs) of the messaging behemoths Tibco and IBM.
According to this article RedHat bought an AMQP implementation from JPMorgan, improved it, then gave the implementation to the Apache Foundation as the QPid project. Currently there is a Java and C++ broker with clients in C++, Java (JMS), Ruby, Pyhton and C# for .NET.
Red Hat has the ambitious goal of enabling a server to process 1 million messages per second.
I guess JP didn't have an interest in maintaining the AMQP implementation, but RedHat are not exactly cheap when it comes to maintenance fees (but so far cheaper than Tibco and IBM).
Update: Microsoft have joined the AMQP working group!
Friday, November 16, 2007
When Network Cables Attack

I bet you this is Time-Warner's data center...
(Picture from http://kevinremde.members.winisp.net/images/yellow_wall.jpg)
Thursday, November 15, 2007
Swing gets even slower by using Vector Graphics
In previous posts I've lamented how Swing had great potential to capture the hearts and minds of GUI developers, but stubbornness on not using native widgets and a bad implementation means they have forfeited GUI applications to competitors like .NET. Most new thick GUIs that our financial clients ask us to develop are .NET GUIs (C# is the language of choice).
I was reminded recently of the pitfalls of the Swing draw-each-widget-pixel-by-pixel approach when I used a simple GUI like JConsole to access an application that I was JMX-ising:

Horrible refresh problem. Swing applications seem to be much more prone to this than native applications.
Can I blame this on the pixel-by-pixel approach, or just Swing's implementation of it? One other implementation of pixel-by-pixel that I played with a few years ago is Thinlet, a remarkably tiny GUI toolkit. I have never put a Thinlet application into production (only recently have clients gotten comfortable with the LGPL license), but I was impressed with the speed of it.
Recently I read an article Nimbus, a new sexy look-and-feel that the Sun Swing engineers are working hard on. When I read that Nimbus used vector graphics I cringed. Even with faster CPUs I bet the performance will still be similar to the current pixel-by-pixel approach. i.e. sucks
Don't get me wrong. Having a vector graphics option is good for some GUIs, but I really wish Sun (or whoever ends up driving the GUI side of Java) would also standardize a fast GUI toolkit. SWT is one option. Thinlet is another.
It is also interesting to note that Android, Google's Java-based framework for developing mobile phone applications, does not include any of the standard AWT or Swing libraries, instead using OpenGL C/C++ bindings.
Shame Sun, Shame for missing the opportunity to take over the desktop.
I was reminded recently of the pitfalls of the Swing draw-each-widget-pixel-by-pixel approach when I used a simple GUI like JConsole to access an application that I was JMX-ising:

Horrible refresh problem. Swing applications seem to be much more prone to this than native applications.
Can I blame this on the pixel-by-pixel approach, or just Swing's implementation of it? One other implementation of pixel-by-pixel that I played with a few years ago is Thinlet, a remarkably tiny GUI toolkit. I have never put a Thinlet application into production (only recently have clients gotten comfortable with the LGPL license), but I was impressed with the speed of it.
Recently I read an article Nimbus, a new sexy look-and-feel that the Sun Swing engineers are working hard on. When I read that Nimbus used vector graphics I cringed. Even with faster CPUs I bet the performance will still be similar to the current pixel-by-pixel approach. i.e. sucks
Don't get me wrong. Having a vector graphics option is good for some GUIs, but I really wish Sun (or whoever ends up driving the GUI side of Java) would also standardize a fast GUI toolkit. SWT is one option. Thinlet is another.
It is also interesting to note that Android, Google's Java-based framework for developing mobile phone applications, does not include any of the standard AWT or Swing libraries, instead using OpenGL C/C++ bindings.
Shame Sun, Shame for missing the opportunity to take over the desktop.
Monday, November 05, 2007
Dynamically add to the Eclipse JUnit classpath
When you run JUnit tests inside Eclipse something that may bite you is the fact that the compile classpath and runtime classpath are separate.
Let's say your Eclipse project directories are layed out something like the following:
PROJ_ROOT
When a JUnit test runs, by default the base run directory and the classpath root is the PROJ_ROOT directory. Therefore, if your unit test loads a file relative to the the PROJ_ROOT, say:
or
it will work. If, however, you've told Eclipse that conf is a "src" directory (i.e. part of the compile classpath) and then try to load a file from somewhere in the classpath from your unit test like so:
it will fail.
So what can you do to change the classpath for the unit tests that need it?
You can manually add the conf directory to the runtime classpath for just those unit tests that need them, but unfortunately so does everyone else in your team.
A cute trick is to change the thread classloader to a URLClassLoader, whose constructor allows you to add URLs (including directories) to the runtime classpath:
To give credit where it is due the above is a slightly simplified version of a solution from my colleague Randy who came up with it when we worked together on a project earlier this year. His solution makes the assumption that the JVMs system classloader is a URLClassLoader (may not be true for all JVMs) and uses a bit of reflection magic to add to the classpath:
Let's say your Eclipse project directories are layed out something like the following:
PROJ_ROOT
- bin
- conf
- src
- test
When a JUnit test runs, by default the base run directory and the classpath root is the PROJ_ROOT directory. Therefore, if your unit test loads a file relative to the the PROJ_ROOT, say:
new FileInputStream("conf/context.xml");
or
Thread.currentThread().getContextClassLoader().getResourceAsStream("conf/context.xml");
it will work. If, however, you've told Eclipse that conf is a "src" directory (i.e. part of the compile classpath) and then try to load a file from somewhere in the classpath from your unit test like so:
Thread.currentThread().getContextClassLoader().getResourceAsStream("context.xml");
it will fail.
So what can you do to change the classpath for the unit tests that need it?
You can manually add the conf directory to the runtime classpath for just those unit tests that need them, but unfortunately so does everyone else in your team.
A cute trick is to change the thread classloader to a URLClassLoader, whose constructor allows you to add URLs (including directories) to the runtime classpath:
ClassLoader currentThreadClassLoader
= Thread.currentThread().getContextClassLoader();
// Add the conf dir to the classpath
// Chain the current thread classloader
URLClassLoader urlClassLoader
= new URLClassLoader(new URL[]{new File("conf").toURL()},
currentClassLoader);
// Replace the thread classloader - assumes
// you have permissions to do so
Thread.currentThread().setContextClassLoader(urlClassLoader);
// This should work now!
Thread.currentThread().getContextClassLoader().getResourceAsStream("context.xml");
To give credit where it is due the above is a slightly simplified version of a solution from my colleague Randy who came up with it when we worked together on a project earlier this year. His solution makes the assumption that the JVMs system classloader is a URLClassLoader (may not be true for all JVMs) and uses a bit of reflection magic to add to the classpath:
public void addURL(URL url) throws Exception {
URLClassLoader classLoader
= (URLClassLoader) ClassLoader.getSystemClassLoader();
Class clazz= URLClassLoader.class;
// Use reflection
Method method= clazz.getDeclaredMethod("addURL", new Class[] { URL.class });
method.setAccessible(true);
method.invoke(classLoader, new Object[] { url });
}
addURL(new File("conf").toURL());
// This should work now!
Thread.currentThread().getContextClassLoader().getResourceAsStream("context.xml");
When Teachers Attack - Caught On Mobile Phone Camera
My own experience of High School showed me teachers were a mixed bag - some excellent, some very average and some very lazy. Occasionally good teachers had bad moments.
I've got mixed feelings about YouTube's 7 Scariest Teachers, a selection of teacher rants caught by students with mobile (cell) phone cameras. Should teachers, who are already struggling to teach unmotivated students, be exposed to public ridicule like this? On the other hand this could help weed out people who shouldn't be teaching.
I've got mixed feelings about YouTube's 7 Scariest Teachers, a selection of teacher rants caught by students with mobile (cell) phone cameras. Should teachers, who are already struggling to teach unmotivated students, be exposed to public ridicule like this? On the other hand this could help weed out people who shouldn't be teaching.
What keywords do recruiters search for?
It's well known that recruiters / job agents do a lot of filtering of resumes using keyword searches. (I get a lot of spam from recruiters based on a technology I might have used once or twice in my career that I mentioned on my resume at some point in the past.)
But what keywords are hot right now? Marketing job website MktgLadder have made available a regularly updated Top 100 Keywords searched for by recruiters. I would like to see this feature added to some of the more IT-centric job sites like Dice.
But what keywords are hot right now? Marketing job website MktgLadder have made available a regularly updated Top 100 Keywords searched for by recruiters. I would like to see this feature added to some of the more IT-centric job sites like Dice.
Subscribe to:
Posts (Atom)