www.weisserth.net : Category Software Development, I work with software every day. I develop software for a living and in my spare time. From my point of view, Open Source software is the way to go. At work, I deal with the Java Enterprise world. In my free time it's mainly Ruby and PHP.

Tracking down your stolen camera? Not impossible!

Fri, 13 May 2011 16:51:00 -0000

Not discussing the recently uncovered privacy issues with Apple’s mobile phones, one impressive feature of an iPhone is that if you’re a MobileMe user, you can use the MobileMe service to track down your stolen iPhone using the GPS and connectivity integrated in the iPhone. If only something like this existed for cameras. I have never lost a camera to theft or otherwise – yet. Nevertheless, I stumbled across a new service online that may help you retrieve your lost camera – given someone else is bold enough to use it and post pictures taken with it on the Internet.

www.stolencamerafinder.com is a new service developed and offered by Matt Burns. Matt’s idea is simple yet effective. Most modern digital cameras store their serial number within the meta data in the images they capture. So when someone is putting images on the Internet, the meta data embedded in the image will contain the serial number. All you got to do is look for images on the Internet containing the serial number of the camera that you lost or that was stolen. So much for theory.

As the Internet is vast place, Stolen Camera Finder (SCF) is limited to images published to Flickr – for the time being at least. So, SCF will not notice images from lost cameras uploaded to places other than Flickr. Flickr is a good start though, as it’s the premier photo sharing platform for photography enthusiasts. In terms of sheer volume, Facebook would be a good place to watch as well.

How does the service work? Well, first you need to find out what the serial number of your lost camera is. You didn’t write it down before your camera got lost? Not a problem, the number will likely be embedded in the EXIF metadata of one of your old pictures. Once you have opened the SCF page in your browser, you can either enter the serial number, provided you know it, or when using a supported browser, you can just drag and drop an image taken with your camera. The image must contain EXIF information with the serial number being part of it. A majority of cameras stores such information.

What happens then is that SCF compares the provided serial number to a database of serial numbers found in images on Flickr. The database is being populated by crawling Flickr and mapping each newly found serial number from the available EXIF information against the URL of the image containing that information. Increasing the number of records in that database that is available to the search that happens when someone enters a serial number in SCF, is done by volunteers running the crawlers that work through Flickr and populate the database. At the moment, the database is still very limited and contains only a fraction of the serial numbers used in Flickr images. As time goes by, this number will increase, but chances are that you won’t even find your own images you uploaded to Flickr yourself.

Anyway, the idea is good. The project is limited by what Flickr allows in terms of automatic programs crawling its site and the fact that only Flickr is considered when searching for serial numbers. There are already reports of people having found images on Flickr from stolen cameras, which is impressively enough showing the use of this service.

For a more technical background of the service, take a look at the SCF page on Google Code.

Java Pattern: try things repeatedly until reaching a timeout

Thu, 26 Aug 2010 06:59:00 -0000

Nondeterministic tests are a common problem in test setups, especially with integration tests. For example, imagine you are doing an integration test of two components that exchange messages where receiving a message in one of the systems changes its internal state which you want to verify. However, the message exchange can be delayed due to external factors (network latency, load etc.). When running tests (for example using the excellent Cucumber framework), testing steps are usually run sequentially. It may happen that the tested system is lagging behind the testing steps, failing your test in some (but not all) cases. You need to make your tests more tolerant for these situations. Often, that means retrying for a couple of times.

How would you implement this pattern in Java? Well, here’s how I did it. I am using a timed runner object that tries an action until it succeeds before it times out. You can define what should happen in case the action times out, by overwriting the abstract method.

/**
 * Use this class to run actions with a timeout. 
 * Actions have to be wrapped within 
 * a yield method of the Yieldable
 * interface.
 */
public abstract class TimedRunner {
  
  private int timoutLength;
  private int elapsedTime;
  private int checkRate = 250;

  public TimedRunner(int length) {
    timoutLength = length;
    elapsedTime = 0;
  }

  public TimedRunner() {
    timoutLength = 10000;
    elapsedTime = 0;
  }

  public synchronized void reset() {
    elapsedTime = 0;
  }

  public void run(Yieldable runMe) {
    for (; ;) {
      try {
        Thread.sleep(checkRate);
      }
      catch (InterruptedException ioe) {
        continue;
      }

      boolean success = runMe.yield();

      elapsedTime += checkRate;

      if (success) {
        break;
      }

      if (elapsedTime > timoutLength) {
        timeout();
        break;
      }
    }
  }

  // just overwrite this method to perform the timeout action
  public abstract void timeout();
}

Now, in other languages, like Ruby or Python you could just call a method and pass it a block of instructions. As that’s not possible in Java, you need to wrap the actions you want to pass within a method belonging to an object you can pass along. That object will be an instance implementing the Yieldable interface:

/**
 * Implement this interface when you want 
 * to use TimedRunner. TimedRunner 
 * expects a Yieldable object, class its yield
 * method and calls it until 
 * it succeeds or a timeout is reached.
 */
public interface Yieldable {
  public boolean yield();
}

The yield() method needs to return a status of success or failure so that the TimedRunner knows when to stop calling it. You could extend/modify this pattern by changing the signature of yield() to match your specific needs.

What should be done in case of a timeout? The most common thing to do would be to fail the test (assuming usage of JUnit 4):

import junit.framework.Assert;

public class FailRunner extends TimedRunner {
  @Override
  public void timeout() {
    Assert.fail("Timed out without success.");
  }

  public FailRunner(int timeout) {
    super(timeout);    
  }
}

In your test code, you would put the nondeterministic code within a yield method and pass it to a TimedRunner instance:

// ... within your test code...

Yieldable runMe = new Yieldable(){
  public boolean yield() {
    // do something here and return true 
    // if it succeeded or false otherwise
  }
};

new FailRunner(30000).run(runMe);

// ...

Feel free to leave feedback in the comments. I would be interested to learn how you handle testing issues such as this one.

Java, arrays, autoboxing and Arrays.asList

Thu, 06 May 2010 16:54:00 -0000

Yesterday, I had some fun with Java again. Since Java 1.5 it has become so natural to mix primitive datatypes with their object based counter parts as Java boxes and unboxes expressions as necessary without the need to make any explicit casts – or so I thought.

Take a look at the code below:

byte[] testBytes1 = {1, 2, 3, 4, 5};
List<Byte> list1 = Arrays.asList(testBytes1);

If you expected that you can create a list of Byte objects from a byte[] array, then you’re sadly mistaken. As Java cannot autobox arrays (which are backed up by a separate type, not equal to the respective primitive elements within), Arrays.asList will not accept testBytes1 since its type is byte[] which is not autoboxed into Byte[]. So above example code is not valid without changes.

It would compile like this:

byte[] testBytes1 = {1, 2, 3, 4, 5};
List<byte[]> list1 = Arrays.asList(testBytes1);

So, now you expect that you will end up with a list of five Byte objects? Wrong again. Look at the expression and its type. The type is still byte[]. So, list1 contains exactly one element, which is an array with five byte literals.

Long story, short answer: before using Arrays.asList loop over a primitive array and copy the elements to an object based array.

Using the MySQL encrypt function in Ruby

Sun, 14 Feb 2010 17:48:00 -0000

If you’re dealing with a legacy MySQL database schema where your users’ passwords are encrypted using MySQL’s encrypt function within your schema and you want to create new records like that using Ruby rather than calling the MySQL function, you can easily do that with Ruby. Ruby supplies a crypt function that does just what the MySQL encrypt function provides. Both implementations use the UNIX C function crypt(3) so you can replace the use of one with another.

The function expects a salt value of two characters. If none is provided, a random string will be used. Take a look at this simple example:

  #!/usr/bin/env ruby -wKU

  def mysql_encrypt(pw)
    
    # compute a random salt value
    # (will end up to be a Base64 encoded string 
    # of random characters)
    salt = [Array.new(2){rand(256).chr}.join].pack("m").chomp
    return pw.crypt(salt)
  end

  encrypted_password = mysql_encrypt("test")

  puts "Encrypted password could be " + encrypted_password

  # we take the first two characters of the already
  # encrypted password as salt value
  # for the re-encryption so we end up with the same value
  
  compared_password = "test".crypt(encrypted_password[0,2])

  puts "The re-encrypted 'test' string is now " + compared_password

Creating hashed passwords using crypt(3) cannot be regarded as secure though. Take a look at the Wikipedia entry on crypt. If you’re implementing any kind of user authentication from scratch, consider using other means of hashing passwords.