Persistent Binary Search Trees

I did some quick search with an eye on persisting indexes on disk, here is what I found:
https://github.com/andylamp/BPlusTree
https://github.com/myui/btree4j
https://en.wikipedia.org/wiki/B-tree
https://cglab.ca/~dana/pbst/
https://github.com/wardbradt/binary-trees-ward
https://github.com/elias-pap/concurrent-data-structures
https://people.csail.mit.edu/jaffer/WB
http://www.cs.cornell.edu/courses/cs3110/2011sp/Recitations/rec24-B-trees/B-trees.htm
https://en.wikipedia.org/wiki/B-tree


On Coding Standards

A good friend of mine sent me this today. Couldn’t say better:

“Always code as if the guy who ends up
maintaining your code will be a violent
psychopath who knows where you live.”
 
-Martin Golding

http://www.csl.mtu.edu/cs1122/www/lectures/04/04_Polymorphism_preclass.pdf

Regards,

Slava Imeshev


Testing Getters and Setters Considered Useful

Writing unit tests for getters and setters is a good idea because such tests create a regression detection suite.

I sometimes hear the argument that setters and getters are not worth unit testing. The logic goes that as they don’t do anything, there is nothing to test. There is a couple of problems with this attitude:

  • First problem: It uses proof by assertion (“Trust me, this method doesn’t do anything [special]”), which is impossible to verify using automated testing tools such as JUnit.
  • Second problem: The behavior of a setter or a getter may expand in future (such as storing the property in a database), and when it happens, there won’t be a unit test to verify that methods still do what they are supposed to do.

Writing a unit test for setters and getters, as trivial as they are at the moment, creates a regression detection suite. This is important because if future changes to the method break it, the unit test will be there to catch the problem.

To make testing matching pairs of setters and getters easier, I usually test them in a single method testSetGet() instead of the pair testSet() and testGet():

Bean:


public class Bean {
   private String property;
   public String getProperty() {
      return property;
   }
   public void setProperty(final String property) {
      this.property = property;
   }
}

Test method:


 /**
   * Tests setting and getting the property.
   */ 
 public void testSetGetProperty() {
       final String testValue = "Test value";
       assertNull("Initial value should be null", bean.getProperty());
       bean.setProperty(testValue);
       assertEquals("Getter should return value set", testValue, bean.getProperty());
 }

Test getters and setters and enjoy the benefits of the growing regression detection suite and the reliability of well-tested codebase.


Password Database for iPhone

Remembering passwords beyond a certain number maybe impossible and that’s where a password database can really help.

Over time we all acquire access rights to a bunch of online systems. Developer machines, production systems, version control, bug tracker, online banking, your home access point, Facebook, twitter, online publications – you name it. Sooner than later those accounts multiple to the point where it is pretty much impossible to remember them all.

How not to store your passwords

Aside from writing passwords down and sticking them to your monitor, there are really two ways to manage passwords:

One way is to develop a system of deducing a password from the name of a website which is known to you only. For instance, get first and last letters of a website, attach your reverse birth date plus some (one) non-alphabetical charter. For instance, a password for this site would look like db0106!. No, this is *not* the password for this blog :-). The problem with this approach is that once this system is known, cracking the rest of your accounts is trivial. Also, there aren’t that many systems to come up with, and any system in a password makes it a subject of brute force attacks.

A much better approach is a secure password database. There are applications that can generate a random, system-less password for each of your accounts and that keep all your passwords in an encrypted database. The database is encrypted using a master password, and this is the only password that you need to remember. Without the master password the database is inaccessible. When you open such an application, it asks for the password and, once the password is verified, decrypts and displays the password database. Only then you can see all your passwords. The password database is better because all your passwords are impossible to guess, and all you need to remember is a single master password.

eWallet

Being an iPhone owner I use eWallet as a password database. There are other password applications but, to my taste, eWallet beats them all. It is convenient, intuitive and flexible. What’s cool is that if you are too lazy you can just photograph your credit cards and store images instead of entering all those numbers.