I'm working on some "star rating" code and I really wanted to round numbers of to the nearest fraction. While the math is really basic, my math skills are rusty and this took me longer to solve than I care to admit. So I thought I'd just blog the solution for anyone else that might find it useful:

round( value/fraction ) * fraction

Like I said, it's very basic math but is very handy when you want to round to something other than to the closest integer.

This morning started off to a rough start. I came in to realize the commit of a merge I made at the end of the day yesterday had failed. Whenever I would attempt to commit the merge changes, it would go through the entire process and then finally fail with a error message of:

org.tigris.subversion.javahl.ClientException: Working copy text base is corrupt

After trying a "Cleanup" and several other steps to rectify the problem, I finally did hit Google to try and find a solution. I came across chris' subversion checksum mismatch - easy workaround which offered several various solutions to the problem.

I tried several of the solutions, but wasn't haven't much success until I came across Michael Sparer's comment:

Thanks for the explanation, which shed some light on how svn manages its working copy. My problem seemed to stem from a bogus file under .svn/text-base, which didn't match the file actually on the server.
- server file (.../x.java): OK
- orig copy from server (.svn/text-base/x.java.svn-base): BOGUS (not same as server)
- checksum (in .svn/entries): matches server, but not server copy

If I can make the bogus copy match what's on the server, then it will also match the checksum, and everyone will be happy.
What I did (i'll call the working dir with the corrupt file "orig-dir":
1. Fresh checkout of svn dir matching orig-dir into /tmp/blah
2. Copy /tmp/blah/.svn/text-base/x.java.svn-base into orig-dir/.svn/text-base
3. Check in successfully

I wish svn would let you refresh a given file from the server...maybe there's a command and I just haven't found it or my svn is too old.

In the end, this ended up being my problem as well. The copy of me .svn/text-base/filename.ext.svn-base was out of sync with the actually copy on the server.

To resolve this, I checked out a clean copy from the server to a tmp folder, then I just replaced the copy in my working folder. After doing this, I was able to check in the file without incident.

NOTE:

I also noticed I had a copy of the template in the .svn/tmp/text-base/ folder. I made a copy of this file and then removed the file this directory before committing. I'm not sure if this step is necessary, but I wanted my local working copy to mirror as closely as possible a fresh working copy.

Recently after installing a fresh copy of Eclipse 3.4 on my PC, I ran into an issue with the "Open Resouce" dialog ([CTRL]+[SHIFT]+[R]) where it was showing all my SVN files. Installing Subclipse is supposed to make the Eclipse IDE automatically hide the .svn-base files from showing up (via the "Team" interface) but it wasn't working out for me.

Turns out there was a very easy solution to this problem—just right click on the project and choose "Close Project" from the menu. After the project closes, just right-click on the project and select "Open Project." This should reinitialize all the settings on a project and appears to registered the handling of automatically hiding the .svn-base files.

An alternative, would be to add the find your org.eclipse.ui.ide_3.4.*.jar (org.eclipse.ui.ide_3.4.2.M20090127-1700.jar) and then modify the plugin.xml file to include the filter "*.svn-base". I don't like this option because it requires you to change a JAR that could later be updated.

If you choose that route, close Eclipse and open the JAR with a Zip extraction tool. Next, search the plugin.xml for the text "<filter". There should be one filter tag:

I was looking for a way to programmatically refresh some specific folders in my workspace anytime I ran my ANT script. Eclipse provides several ant tasks that you can use for various purposes, once of which is the <eclipse.refreshLocal /> tag:

<eclipse.refreshLocal resource="MyProject/MyFolder" depth="infinite"/>

• resource is a resource path relative to the workspace 
• depth can be one of the following: zero, one or infinite

However, when I first tried adding this task to my ANT script, I was getting an error that looked like:

BUILD FAILED
c:\path\folder\build.xml:85: Problem: failed to create task or type eclipse.refreshLocal
Cause: The name is undefined.
Action: Check the spelling.

Needless to say, I was pretty confused. So after some brief research, it turns out I accidentally running ANT outside of the Eclipse JRE. To fix this, go open up the External Tools Dialog (Run > External Tools > Open External Tools Dialog...) and make sure the JRE tab is set to "Run in the same JRE as workspace."

I'm not sure how that setting got changed, but I'm glad I found the fix. This also has sped up the first time execution of my ANT scripts.

We recently bought a Self-Signing Cert from Comodo through Tucow's Authors site. Through Tucows I was able to get a 3 year cert for $195—which is cheaper than a 1 year cert from either Thawte or Verisign.

I was expecting them to send me a cert via e-mail, but instead they install the certificate into the browser in which you purchased the certificate. From this point on Comodo doesn't offer any instructions on how to use the cert, so I had to do some research.

First, I'd recommend buying your cert using Firefox. If the cert gets installed into Internet Explorer, you need to jump through a bunch of hoops to generate the p12 file from the pvk format. Once you have your cert stored as a PKCS12 file, the steps for signing your Java Applet are pretty straightforward.

The instructions below show you how to sign an applet provided your personal cert has installed into Firefox. If you already have your p12 file, the you can skip to step 11(the directions use the filename of self-sign.p12 for the exported key.)

1. Open Firefox v2.x
2. Go to Tools > Options...
3. Click on the Advanced button
4. Go to the Encryption tab
5. Click on the View Certificates button
6. On the Your Certificates tab you should see your personal cert
7. Click your personal cert
8. Click the Backup button
9. Save the file to your desktop as: self-sign.p12 (the p12 extension will be added for you automatically)
10. Enter a password for the certificate when prompted by Firefox (you'll need this value later)
11. Now that the cert has been exported, we need to get the "alias" so we know what to use when signing the applet.
12. From a command prompt run:
    keytool -list -storetype pkcs12 -keystore /path/to/your/self-sign.p12
    
    (The keytool is a command line tool located in your JDK's /bin folder.)
13. Enter the password you assigned in step 10

14. You should now see some output that looks like:

    Keystore type: PKCS12
    Keystore provider: SunJSSE

    Your keystore contains 1 entry

    [Alias], Jan 1, 2008, keyEntry,
    Certificate fingerprint (MD5): hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh

    The [Alias] is a string that might be look like a UUID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx) or it could just be string of various text. The alias will be the part of the text up to the first comma before the date.

15. To sign a jar, we use:
    jarsigner -storetype pkcs12 -keystore /path/to/your/self-sign.p12 yourJar.jar [Alias]
    
    Or if you prefer Ant, you can use something like:
    <target name="signjar" depends="jar">
      <input
        message="Please enter keystore password:"
        addproperty="keypass" />
      <signjar jar="${lib}/yourJar.jar" storetype="pkcs12"
        keystore="/path/to/your/self-sign.p12" alias="[Alias]"
        storepass="${keypass}"/>
    </target>

I highly recommend creating an Ant build.xml script for compiling and signing your JAR. The biggest benefit is once you get it set up, there's nothing manual you need to do.

I've been working on a Java applet that can get images from the user's clipboard or take screenshots of the user's desktop and upload them to a server via HTTP. The last piece of the puzzle was to make sure I could access the task methods via JavaScript, as the interface will most likely be driven by HTML.

I've been using a self-signed cert to sign the Java Applet so that I can access the user's clipboard and take the screenshot. All of this was tested and working extremely well from if I used the Applet UI. However, as soon as I would try to invoke one of the sandboxed functions from JavaScript the applet started throwing the error:

AccessControlException is thrown: access denied (java.awt.AWTPermission accessClipboard)

I tried a number of things to get around this problem. I thought it was something I was doing wrong when I was signing the applet (since it was working fine from within the Applet's built-in UI controls.) After playing around with the cert signing process and getting no where, I finally came across the post JavaScripting in Applets - Getting Out of the Sandbox where a comment from Stéphane Bury pointed me to a solution.

public static void doSpecialWork(String param1){
    final String fParam1 = param1;
    java.security.AccessController.doPrivileged(new java.security.PrivilegedAction() {
        public Object run() {
            // put the code of your method here
            ...
            ...
            return "";
        }
    });
}

My final solution was to write a command() method which I can use to trigger off the internal privileged methods:

/**
 * The method to invoke from JS to perform the privileged methods--which throw
 * security errors if you try to access them directly.
 * 
 * @param command - the command you want to perform (clipboard, screenshot, upload)
 */
public void command(String command){
    final String cmd = command;

    java.security.AccessController.doPrivileged(
        new java.security.PrivilegedAction(){
            public Object run() {
                // execute the privileged command
                executeCommand(cmd);
                // we must return an object, so we'll return an empty string
                return "";
            }
        }
    );
}

As you can see the method is very basic, it just passes the command it received to a private method which actually executes the command. Now I can access any of the privileged methods in my applet with this little helper method.

One thing I rarely ever do in Java is program anything that requires a desktop UI. If I'm doing any Java programming, it's generally server-side related. Recently that changed when I began working on a Java applet that allows users to upload images (screenshots) in their clipboards directly to the server.

Building the basic applet was pretty straightforward. Even signing the applet (so you can actually query the operating systems clipboard) is pretty straightforward—made even easier once I created an ANT build script.

The applet was progressing nicely, well that's until I tested things on the Mac.

As I mentioned early I've been working on a SVN post-commit script. We've got a SVN repository that will be modified by several remote developers and I really need to keep an eye on this repository and I need to closely monitor changes to this repository.

There are two major functions that I needed in my post-commit script:

1. I needed to update the working copy on my server
2. I needed to e-mail the changes to myself, so I know when developers are making changes

There are an abundant of examples showing off how to do this in various *nix flavors, but I couldn't find any good Windows-based solutions that didn't require Perl to be installed on the server. That led me to create the following post-commit.bat script.

I've been working on a post-commit hook for our Subversion install and was running in to a number of issues. The post-commit.bat file would run fine from command line, but I just could get things to work as I expected from SVN. After much debugging and scouring Google for answers, I've found a few tips that will hopefully help you to troubleshoot your own SVN repository hooks.

1) Subversion executes all hook programs with an empty environment

This was the biggest issue I was running in to, because I was expecting the my script to be able to find any programs in my %PATH% statement. That's the main reason my scripts were working fine from command line, but were breaking when executing from my SVN hook.

Whenever the topic of my employment comes up, everyone's first reaction when I tell them I work from home is: "Wow, that must be really nice!" While working from home definitely has some benefits, it has some cons.

As Cameron Childress mentions in his post on Coworking in Atlanta, the two hardest things to adjust to are the lack of socialization and self motivation—both are issues Cameron and I have talked amongst ourselves about in the past.

I recently posted about a new open source Java project called AntiSamy—which allows you to protect your websites from XSS hacks. I also promised that I'd soon show you some code examples that show you how you can use AntiSamy within ColdFusion.

I've only tested this code under ColdFusion 8. It should theoretically work on any ColdFusion installation, provided you're using a JDK version that supports the compiled version of the AntiSamy code (which is compiled to Java v1.5.)

Before you can actually use AntiSamy, there are a few quick steps you need to make.

An extremely common problem web developers face is protecting themselves from XSS exploits. Any webpage that takes input from a user and displays it is potentially at risk. The simplest way to protect yourself from this type of exploit is to remove anything that could interpreted as HTML by the browser—either by escaping the content or by using removing it altogether.

However, there are many use cases where you may want to allow a user to enter some HTML markup—to allow for basic formatting. Browser tools such as XStandard, FCKeditor and TinyMCE all provide developers with easy ways to provide users with rich text formatting capabilities, but allowing users to input HTML opens your site up to the possibility of XSS attacks.

I have to admit, I only use a small portion of the features that are in Eclipse. That's because there are so many features that I often miss things, even buttons that stare me in the face everyday. I love Eclipse, it's a really powerful IDE and one of the most impressive uses of client-side Java that I've ever seen.

Yesterday Michael Henke posted a nice entry (complete with screenshots) on some of the features of the Eclipse Navigation Toolbar. I've used the "Go Into" feature quite a bit. If you have a large project that you're going to be working in exclusively, it's a nice way to keep your navigation tree to just the relevant files and folders.

However, I must admit that I've never taken the time to figure out what the "Link With Editor" button does. I've clicked it once or twice, but never saw an immediate purpose for the button. Thanks to Michael's post, I know now that the clicking the "Link With Editor" toggle button will cause the Navigation pane to automatically jump to the active file open in the current editor tab.

Since I often have many tabs open at once (sometimes even dozens) I can see this feature being useful. Especially since often related files are grouped together in my project.

Adobe Labs just released BlazeDS as a new Open Source project (released under the LGPL v3 license.) Essentially BlazeDS is the remoting and messaging technology behind LiveCycle Data Services. For people familiar with Adobe Flex, they know that this is the "push" technology that allows you to build interfaces that are updated automatically when the data on the server changes. This means you can make data on the screen change in realtime as changes on the server occur.

I spent a few minutes looking through the BlazeDS documentation, but didn't see any real good information related specifically to ColdFusion. However, according to the Release Notes it looks like you can integrate BlazeDS directly with ColdFusion 8.