SmartSVN Blows the other Subversion Clients out of the Water

I was a developer in a Window's environment for many years and have had a few years of experience with TortoiseSVN. Once I switched to Ubuntu a while back, I strugged to find a suitable replacement for TortoiseSVN in Linux. I tried a few different solutions including RapidSVN and KDESVN. Neither of those even came close to the ease of use and stability of TortoiseSVN.

A friend who develops on OS X had mentioned that he uses SmartSVN and that it is available for Linux also. As a matter of fact, you can run SmartSVN under Windows, OS X, Linux, and even OS/2 Warp.

So I downloaded it and ran through the 30 day professional version trial. At the end of the trial I immediately paid the fee for the professional version. I know what you're all thinking. This sucker paid $79.00 for a Subversion client when there are a billion free ones available. I gladly paid the fee and say with great confidence that there is nothing out there that even comes close to what SmartSVN can do for you.

Even if I was still developing in a Windows environment and could still use TortoiseSVN, I would have paid the fee to use SmartSVN. TortoiseSVN does not even come close to the level of productivity I can accomplish under SmartSVN.

Merge Single Revisions Across Branches

I work in an environment with many different branches. At any given time I have to work on the trunk and two or three branches. If there is a change that needs to go into the trunk and possibly one or two branches, it is a time consuming process to get the changes everywhere they need to be.

Assuming I am using TortoiseSVN, I'll have to commit the changes to the trunk. Then using a diff tool, merge the changes I made from the trunk to the branch. It is all very manual and error prone. TortoiseSVN does offer a merging tool, but this is only to merge the entire branch, not single revisions or files but it is uselessly complicated in my opinion. You can read more about TortoiseSVN's merging functionality here.
Using SmartSVN, this same task is so simple. After you have commited your trunk changes, switch over to the branch where you wish to merge these changes to. Right click on your trunk commit in the transactions pane and click merge. This will merge the changes from that revision into your working copy of the branch. After that, simply commit to the branch.
If you only want to merge one or two files from a given commit, you can do that too. The amount of time this saves is huge when you don't have to manually merge these changes across branches.

Conclusion

The capability to merge single revisions across branches is huge, but there are still many other features that separate SmartSVN from the pack. For more detailed information on SmartSVN, check out their site at: http://www.syntevo.com/smartsvn/index.html

Also, just for the record, I'm not affiliated with Syntevo or receiving any compensation for this post.

Test your Java Regular Expressions ( REGEX ) Online

If you've ever worked with regular expressions using the java.util.regex package in Java, you know it can be a slow process to thoroughly test your regular expression. I recently found a website that allows you to test your regex using the java.util.regex package and actually provides detailed feedback.
Using fileformat.com's Regular Expression Test Page, you can run test data through Java's regex engine and see the Matcher's output methods such as matches(), replaceFirst(), replaceAll(), lookingAt(), and find(). It will also show you the groups your regular expression creates.

The next time you are writing some fancy regular expressions for use in the java.util.regex package, make sure you use this handy tool for testing your regex in Java.

Fixing Slow Internet Browsing when using Firefox on Mac OSX

If you're using Firefox on your Mac and having issues with slow web browsing, it may be due to the fact that Firefox is attempting to do IPV6 DNS lookups. The main symptom for this problem is that every time you attempt to browse to a new page, the status in the bottom left corner says "Locating whatever website..." and it takes a few seconds before the page starts to load. However, once you get to the page, browsing speeds up.

The problem is that Firefox attempts to resolve IPV6 addresses first then attempts to resolve IPV4 addresses by default. If your ISP's DNS server does not support IPV6, this will cause a delay. Fortunately, the good people at Mozilla gave us a way to change this setting.

To fix this, you can disable IPV6 in Firefox by following the steps below:

1. Open Firefox, type about:config in the address bar and hit enter.
2. You'll receive a warning, click the button that says "I'll be careful, I promise!"
3. Find the preference named network.dns.disableIPV6 and double click it to set it to true.
4. Restart Firefox

Now your browsing should speed up because Firefox will now only attempt to resolve addresses in IPV6 format. For more information about this issue check out http://kb.mozillazine.org/Network.dns.disableIPv6.

Securing Grails: Salting Passwords using the ReflectionSaltSource

I'm a Grails newbie, however I have been using Spring Security for quite some time. One of the features I really like about Spring Security is the capability to provide either a system wide salt or reflection salt source for more secure password hashing.

As I was getting started on a Grails project, I was impressed with how easily the Acegi Spring Security plugin integrated with my project. However, after adding a few users with the same password, I realized the passwords were not being salted with user properties because all of the hashes were the same.

In order to add a Spring ReflectionSaltSource to our Grails authenticationDao, we'll need to start by declaring the salt source in our resources.groovy file.

import org.springframework.security.providers.dao.salt.ReflectionSaltSource

beans = {

    saltSource( ReflectionSaltSource ) {
        userPropertyToUse = "username"
    }

} 

The code above creates a saltSource bean that we can use for dependency injection throughout our Grails project. The next step we need to take is to inject our ReflectionSaltSource into the daoAuthenticationProvider. I chose to do this within the bootstrap.groovy file. Below is a sample of my BootStrap.groovy.

class BootStrap {

     def daoAuthenticationProvider
     def saltSource

     def init = { servletContext ->

          daoAuthenticationProvider.saltSource = saltSource

     }

     def destroy = {}
}

We have now setup Acegi authentication to use our ReflectionSaltSource using the username property. However, one more gotcha remains. If you generated the RegistrationController using the Acegi plugin, you'll need to change how it encodes passwords for new users. Otherwise, it will continue to encode passwords the old way and authentication will never succeed.

In the RegistrationController, you'll see where it is calling on the authenticateService.encodePassword method to encode new passwords. Simply change that call to use the daoAuthenticationProvider's passwordEncoder like so:

daoAuthenticationProvider.passwordEncoder.encodePassword( passwd, username )

Now all of your users' password hashes will be salted with their username. Keep in mind, that you can't allow users to change their usernames otherwise, they will not be able to login. This simple step makes your Grails application more secure as intruders will not easily be able to identify common password hashes if they get access to your database.