if you're like me who likes to download stuff from time to time untraced, this mac os x script might be useful. i use the ipredator vpn but find that the connection drops frequently, especially initially. to ensure the vpn connection reconnects automatically, follow these simple steps:

append persist to /etc/ppp/options. if it doesn't exist, create the file. you'll need to do this with admin privileges. e.g.:

sudo echo "persist" >> /etc/ppp/options

open AppleScript editor and enter the following replacing the "VPN" with the name of your vpn connection name:

tell application "System Events"
  tell current location of network preferences
    set VPNservice to service "VPN"
    if exists VPNservice then connect VPNservice
  end tell
end tell

compile and run the AppleScript to verify that it works. if it does, save it as an „Application“. running this application will ensure that your vpn connection starts and reconnects when dropped.

thanks to yves-vogl for the script.

ERROR: Maven JVM terminated unexpectedly with exit code 137

MAVEN_OPTS=-Xmx1536M -XX:MaxPermSize=786M -Dgwt.compiler.localWorkers=1

thanks to Lymedo for his entry at wdc community:

1. These instructions assume that you know how to use the Terminal App in Mac OS X.
2. If you already have a Time Machine backup on the My Book Live you will lose it.
3. You need to have SSH enabled on the My Book Live.
4. You should have some understanding of the RSYNC utility in Mac OS X. If you don't then read up on it before you start.
5. You will ?need to create a terminal session on the My Book Live (I use sshXgui off the Mac App Store)
6. I am running OS X Lion - steps might be differnent in other versions.
7. From here on My Book Live will be referred to as MBL, Time Machine as TM and the name of your Mac as YourMac.

If you already have a TM backup on the MBL go to Step 5.

1. Go to Time Machine Preferences
2. Click 'Select Disk…'
3. Choose the volume called "Time Machine on "MBL-backup"
4. Select 'Use Backup Disk' and select 'Back Up Now'. This will automatically create a sparsebundle in the TimeMachine directory on the MBL backup volume. Let Time Machine backup a few MB of data and then stop the backup. Turn off TM backups in the preferences so it doesn't try and start up whilst you are completing the following steps.

5. Create a Terminal session on the MBL and use the ls command to list the contents of the TimeMachine directory on the backup volume:
Username: root
Password: welc0me
Command: ls /DataVolume/backup/TimeMachine/?
This is how it should look when complete:

MBL:~# ls /DataVolume/backup/TimeMachine/?
YourMac.sparsebundle Network Trash Folder Temporary Items
MBL:~#

*** The sparsebundle in this directory is the one you are going to replace ***

6. Create the new sparsebundle on your desktop using the following command in a local Terminal session:

Change the 250g to whatever size in GB that you what the size to be. Replace USERNAME in the command to your Mac user name. Replace "YourMac".sparsebundle with the name of the sparsebundle from Step 5.

*** Once created, open the sparsebundle with Disk Utility and set 'Enable Journaling' ***

7. Copy the new sparsebundle to the root of the default Public share on the MBL (this is only to make the rsync command easier to write - you can delete this file after the rsync command is complete).
8. Now you can run the rsync command to replace the sparsebundle created in Step 4 with the sparsebundle created in Step 5. Using the terminal session on the MBL:

This command copies the new sparsebundle from the Public share (ref. Step 7) to the TimeMachine directory on the backup volume (ref. Step 5). THIS MAY TAKE SOME TIME.

9. Turn TM back on in the preference pane and start the backup IN FULL. You might get a warning saying the identity of the backup has changed. If you do select the option to use the new one.

i'm no expert in writing shell scripts, so when i come across gems like these i should blog or at least make a note of it. so here goes, thanks to stackoverflow.

dir=$(cd -P -- "$(dirname -- "$0")" && pwd -P)

now that it is no longer expected of me to keep what we've been working on in the last couple of months hush hush, here are some infos for the time being:

more infos coming soon....

you may have noticed, if you have hudson ci build an android test application, that the build succeeds even though you might have failed unit tests. at least this was our case given the following configuration:

• Android SDK Tools Revision 8
• Hudson CI with the Android Emulator Plugin
• Hudson build job for android test application executing ANT target run-tests

for Android SDK Tools Revision 8, ANT target runt-tests is defined within tools/ant/test_rules.xml. one can adjust this file, but recommended is to override targets from within your android application or your android test application. in our case (the run-tests case), this is done by adding the following (customized targets originally defined in test_rules.xml) to your android test application build.xml just before the <setup/> element.

<macrodef name="run-tests-helper-custom">
    <attribute name="emma.enabled" default="false" />
    <element name="extra-instrument-args" optional="yes" />
    <sequential>
        <echo>Running tests (custom configuration, project specific)...</echo>
        <exec executable="${adb}" failonerror="true" outputproperty="tests.output">
            <arg line="${adb.device.arg}" />
            <arg value="shell" />
            <arg value="am" />
               <arg value="instrument" />
            <arg value="-r" />
            <arg value="-w" />
            <arg value="-e" />
               <arg value="coverage" />
               <arg value="@{emma.enabled}" />
            <extra-instrument-args />
            <arg value="${manifest.package}/${test.runner}" />
        </exec>
    	<echo message="${tests.output}"/>
	<fail message="Tests failed!!!">
            <condition>
                <contains string="${tests.output}" substring="Failure" />
            </condition>
	</fail>
    </sequential>
</macrodef>

<!-- Override in order to use custom run-tests-helper-custom macro -->
<target name="run-tests" depends="-install-tested-project, install"
            description="Runs tests from the package defined in test.package property">
    <run-tests-helper-custom />
</target>

the adjustment boils down to in having a <fail/> message with an associated condition. this will allow hudson to recognize whether tests have failed or succeeded and mark the build status appropriately.

i simply had to blog this just because it is so simple, it worked the first time and because it is, well pretty cool...at least for a geek like myself ;-)

public class SmsReceptor extends BroadcastReceiver {

  private static final String TAG = SmsReceptor.class.getName();

  @Override
  public void onReceive(Context context, Intent intent) {

    Bundle intentExtras = intent.getExtras();

    if (intentExtras != null) {
      Object[] pdus = (Object[]) intentExtras.get("pdus");
      StringBuffer smsBody = new StringBuffer();
      SmsMessage[] smsMessages = new SmsMessage[pdus.length];
      for (int i = 0; i < smsMessages.length; i++) {
        smsMessages[i] = SmsMessage.createFromPdu((byte[]) pdus[i]);
        smsBody.append(smsMessages[i].getMessageBody());
      }
      Log.i(TAG, String.format("Received following SMS: '%s'", smsBody));
      Toast.makeText(context, smsBody, Toast.LENGTH_LONG).show();
    }
  }

}

<receiver android:name=".receiver.SmsReceptor" android:enabled="true">
	<intent-filter>
		<action android:name="android.provider.Telephony.SMS_RECEIVED" />
	</intent-filter>
</receiver>

<uses-permission android:name="android.permission.RECEIVE_SMS"></uses-permission>

thanks to this article, i found a very handy script for easily getting the source code applicable to one's android.jar version. more detailed info here.

#!/bin/sh 

SRC_DIR=/tmp/android-api

print_syntax() {
   echo "Syntax:\\n\\t$(basename $0) [option]"
   echo "\\nOptions:"
   echo "\\t-l prints available versions"
   echo "\\t-v builds jar file with sources of specified version"
   echo "\\t-c cleans up the sources from the temp directory\\n"
   exit 1
}

error() {
   echo "Error:" $1
   exit 1
}

download_sources() {
    if [[ ! -d $SRC_DIR ]]; then
        git clone git://git.source.android.com/platform/frameworks/base $SRC_DIR
    fi
}

if ! which git > /dev/null ; then
    error "git not installed (or not in the PATH)"
fi

if ! which jar > /dev/null ; then
    error "jar not installed (or not in the PATH)"
fi

if [[ "$1" == "-l" ]]; then
    download_sources
    cd $SRC_DIR
    git tag -l
    exit 0;
fi

if [[ "$1" == "-c" ]]; then
    rm -rf $SRC_DIR
    exit 0;
fi

if [[ "$1" == "-v"  && ! -z "$2"  ]]; then
    JAR_FILE=$(pwd)/$2-src.jar
    download_sources
    cd $SRC_DIR
    if ! git tag -l | grep $2 ; then
        echo "Version \\"$2\\" not found"
        exit 1;
    fi
    git checkout $2
    touch $JAR_FILE
    find . -depth 2 -name "java" -type d -exec jar uf $JAR_FILE -C {} . \\;
    exit 0
fi

print_syntax

in case you're using the very useful deploy plugin for the hudson continuous integration server, you're likely to run into memory issues after deploying to a tomcat container numerous times. this is a common issue for application redeployments on a running tomcat.

adding a stop and start (restart) tomcat shell script to the hudson job, does give tomcat a clean bill of memory, but you'll notice, even after a successful application deployment, tomcat no longer runs after the hudson build/job is complete. regardless how you script it, tomcat no longer runs as a background process. none of the processes spawned by any of hudson's build/job shell scripts will remain running.

unless, here comes the money shot, you add the following:

BUILD_ID=dontKillMe

hack or not, it does the trick nicely.

in essence, the enabled derived property will hide the resource from any "open resource" (CTRL+SHIFT+R) navigation. if you've worked with maven, the target directory is an ideal candidate for the derived property. no longer will you have duplicates or more appearing in your open resource dialogue, but only the one (if found) resource typically kept in a team repository.

i discovered this in the developer's documentation for iteraplan.de. just another reason why i love freelancing :-)

• Beers by the river (@ The Lucky Shag) http://t.co/d55KKf8d (posted )

• Not quite the München #Oktoberfest but close enough http://t.co/50Q7yGlU (posted )

• At least I didn't have pesky snakes #perth @ Herdsman Lake Wildlife Centre http://t.co/sXGizmGN (posted )