Bad news, It seems with the assignment rush and the exam cram time coming I’m finding it hard to find time to study. This means the lowest priority things get pushed off my TODO list. Sadly this means I won’t be blogging until mid November. Thanks for understanding.
To play me out, this commercial. Try to guess what product they’re advertising.
Random Thought: I know this sounds crazy, but if anyone wants to write an article during the hiatus just check me an email. You’ll get full credit.
If you’ve never heard of subversion before then you are in for a pleasant surprise. Subversion is a version control tool, which means it will keep track of several files and all their old versions. Normally subversion is used to help multiple people work together on a single project. It tracks all their changes and combines them all, even flagging when conflicts occur and assists in resolving them. It is also useful when working alone on a school assignment. Here’s a few dot points that capture the essence of why Subversion is useful with assignments:
Subversion allows you to work on the same assignment on multiple computers.
Subversion can email you with changes you’ve made, allowing to review them.
Subversion allows you to show a teacher that you’ve been working on an assignment over the whole time available and not just in the last few days. this gives you greater leverage when asking for an extension.
Subversion can help you prove in a disciplinary hearing that you did not plagiarise any code from others showing the natural growth your code had.
Subversion can get back that file you just accidentally emptied out of the trash.
Subversion can show you all the changes you made between the time you fixed that annoying bug, and now, when you just reintroduced it.
The first step to making an assignment in is to build your repository. If you didn’t do this first that’s okay, you can easily import an existing project into a subversion repository. To create a repository you simply use the ‘svnadmin create’ command. You should then create some folders that should be in every subversion repository (trunk, tags and branches). This next block of commands will show you how to create the initial project. If you’re using these instructions to import an existing project just copy your files into the trunk folder before you run the ‘svn import’ command.
The trunk, tags and branches folders aren’t strictly required but can be very useful in certain circumstances. The trunk folder is where you main copy sits, it should be the latest stable version of the software. In an assignment though this is where you will probably be doing all your work, you generally don’t have the need or the time to make and merge branches. Which leads us to branches. Generally you branch software when you are about to make a major change that may break other developers work. You most likely don’t have other developers on your assignment and if you do you’ve probably all decided on what parts you will work on. Finally tags are for labelling certain versions with a specific tag. For example if you have to submit your assignment weekly you could tag each week as you submit, or you could tag as you finish each requirement. To populate these folders you just copy whatever it is you want into them. Subversion will only use a minuscule amount of space as the copy will be stored internally to the repository.
Before you can edit the files in the repository you need to check it out. You can check it out to the same machine, you can use SSH or you could check it out over WebDAV depending how you’ve set it up. The following command checks out the trunk folder into a folder called newproject. This is one of the few times you have to type the full path to the repository. Subversion remembers this for you so that next time you use a subversion command its pre filled.
What you’ve just checked out is called a ‘working copy’. This is where you make your changes before uploading them again in to the repository. Your working copy also includes copies of the versions you originally checked out so that if you want to revert back to them you can. Because they are stored in the working copy you don’t need access to the repository to revert. To revert back to the version you checked out from the repository you simply run ‘svn revert <filename>’. You can also find the differences between these versions and the current ones by using ‘svn diff <filename>’. The filename is optional and if omitted will print all the changes in the current directories and below.
Part 2 to come… Random Thought: I’ve just redesigned my website, I’d love to know what my readers think. If you could post your comment on the new design, I’d appreciate it.
One of the biggest features of Java 1.5 was generics. In particular all the collection classes had been extended to use parametrized classes. Normally the collection classes accepted and returned Objects which is the class all other Java classes descend from. Unfortunately this meant that you had to cast everything you got back out of a collection to what you expected it to be. and until you did you would only be able to call methods that were provided by Object. You also had to be ready to catch an exception in case the class could not be cast because it was the wrong object.
Generics and parametrized classes allow Java programmers to place a type on a class and have that type inherited by its methods. For example you can now declare an ArrayList class with a type String. This alters the ArrayList class so that its add method now only accepts objects of type String, the get method now also returns objects of type String. This makes everything type safe which means you don’t have to cast anything and your code won’t compile if you try to put something in the ArrayList that doesn’t match its class.
Java uses parametrized classes to build its collections and you’ll want to use them too if you’re making your own collection class. For example if you were implementing a stack, a queue or a multi-priority FIFO queue are good cases for parametrized classes. Be careful though of the lure parametrized classes can have. They are not a replacement for polymorphism and shouldn’t be used when polymorphism would make more sense. For example if your multi-priority queue gets the priority out of the object itself then you’d need an interface that provides a method to get the priority. Then your class will only be able to accept items that implement that interface, which makes sense in this case as we need to priority to be able to store it.
A parametrized class is really simple to use. Here is an example implementation of a stack collection backed by an ArrayList:
import java.util.ArrayList;
import java.util.Collection;
/**
* This class acts as a stack. Items can be 'pushed' which adds them to the top
* of the stack. items can also be 'popped' which removes and returns the top
* item on the stack and removes it. This means only the most recently added
* item is available at the current time. To get to older items you need to
* first remove the others.
*
* Note: Java already has a stack object that should probably be used in
* preference to this one. This is only an example implementation.
*
* @author Daniel Hall <daniel@danielhall.me>
*
* @param <T> The type of items that can be stored in the Stack.
*/
public class Stack<T> {
/* Uses the same type as this class to store the items */
private ArrayList<T> array = new ArrayList<T>();
/**
* Creates a Stack containing items already in a collection. The collection
* must have the same parameterized type as this class to ensure that we get
* the right objects.
* @param c The Collection to initialize with
*/
public Stack(Collection<T> c) {
array.addAll(c);
}
/**
* Creates an empty Stack object
*/
public Stack() {
}
/**
* Adds an item to the top of the stack.
* @param item The item which will be added to the top of the stack.
*/
public void push(T item) {
array.add(item);
}
/**
* Removes the first item from the stack
* @return The item that was on the top of the stack.
*/
public T pop() {
/* This gets the size so we don't have to do it twice. */
int count = array.size();
/* If the stack is empty return null, note that the Java implementation
* of stack throws an Exception instead.
*/
if (count == 0) {
return null;
}
/* Remove the last added object (which will have index count - 1) */
return array.remove(count - 1);
}
}
Random thought: John Lions wrote a book about the Unix source code, in the seventies, which because it also included some code, was blocked from being published until 1996.
Most people wanting to generate random numbers in Java do something similar to the following:
public static void main(String[] args) {
Random generator = new Random();
int randomnumber = generator.nextInt(5) + 1;
System.out.println("Dice rolled: " + randomnumber);
}
This is perfectly fine for a simple dice rolling application where there isn’t going to be much effort put into cracking it. For example in this application the only real reason you would bother cracking it would be to show off a neat party trick to your geeky friends. No doubt though the effort wouldn’t be worth it.
Java states that the Random class and its subclasses must produce predictable results when seeded with the same data. This however is not why this is insecure, and it is useful when testing. The reason that this class is predictable though is the way in which it is seeded. The Random class, in the absence of a seed in its constructor it will seed its random number generator with the current time in milliseconds. This means that if somebody knows the time that the Random object was seeded and has several consecutive bytes of output then they can reasonably predict the next numbers. Once somebody has discovered the seed for the generator all number produced from it can be seen as compromised.
The SecureRandom Class
The SecureRandom class is different, it again uses algorithms that when seeded will produce predictable results, but the algorithm is much more complex. It uses a digest algorithm such as SHA-1 on the seed and a counter to generate random data. SHA-1 is much more costly than the simple algorithm used in the Random class and as such it is much harder to brute force.
Its true strength however lies in the method in which it is seeded. The SecureRandom class is seeded using true random data gathered by the operating system. This is data gathered by the OS from sources of true randomisation, such as mouse movements, network packet arrival times, IO statistics and interrupts. On Linux the data is gathered from /dev/random and on Windows via the CryptGenRandom() call in Windows.
When using SecureRandom though you should be aware of a few things:
The more random numbers some can get a hold of the more likely they can figure out the seed. You should either throw away the SecureRandom object every now and then or reseed it. Keeping in mind the next point though.
The seeding the generator takes entropy out of the system, if it cannot get any entropy it will block until the system has some. This means if you’re reseeding the generator too often your program will hang along with anything else on the system requiring entropy.
Don’t seed the SecureRandom class yourself, unless you are 100% absolutely sure you are seeding it with purely random data, or you are testing and need repeatable results. Whatever you do, don’t let your testing code leak into a production system.
How to decide
Generally when you’re coding you don’t need secure random numbers. For example if you’re writing a number guessing game, or a quiz generating program then high quality random numbers aren’t required. It should be noted though that if money is involved people will often go to greater lengths and a more secure generator will be required, such as in a slot machine.
Again generally if what you are generating is a security token of some sort then you will need a secure generator. For example a session id, a one time password or an encryption key. The exception here is a salt for a password, salts can be generated using predictable entropy sources, even a simple time stamp would work here (especially if your also storing the time stamp to measure password expiry).
In an act that appears to contradict both the ‘do no evil’ and the ‘android is open’ mantras of Google they sent a Cease and Desist to CyanogenMod creator Cyanogen. This effectively means that all cooked versions can now no longer include and Google applications, sync with Google services or the many other closed source parts of the ROM. I use Cyanogen’s mod and this effectively cripples it to a worthless Linux phone distribution. Google have essentially said to me “You know that T-Mobile G1 you brought that was supposed to be completely open? Well we never made all the good bits open, and now we’re taking them away.”. I can’t use the Official ROM because I live in Australia and it constantly sends text messages to T-Mobiles myFaves which costs me a fortune. So Google has removed my ability to use their services on my ‘Google’ phone. So now wherever you read a press release where Google claims that Android is open you know what they really mean is they made the stuff they had to open and closed the rest.
I see only one way out of this mess, we need developers to replace all the closed source parts of Android with free software solutions. This means Android will be free and fully open source. Why stop there though? Lets make Google’s decision into one they will regret! As the open source community is replacing the closed source apps we should build in functionality to allow the phone to work with Google’s competitors. When you first used the G1 you had to sign in using your Google account. What if that same box let you sing in with your Live Id, your Yahoo account or even OpenID? Imagine the Android phone being written in completely open source to work on any operator! It wouldn’t be hard either, most are beginning to provide APIs to their accounts and I’m sure they’d love to help.
Edit: According the the Save Cyanogen Petition application on the market it is impossible to even run the ROMs that Google claim to support without the Google binaries.
None of the opinions that I express on this site are representative of the opinions of my employer, my family, my friends or any other person. I speak only of my own opinions and others are free to express their own opinions whether they agree or disagree with mine. Comments on this site are representative of their respective author and no comment will be removed simply because I disagree with the opinion stated within. Comments will be removed if they are offensive, derogatory, spam, inaccurate or in anyway harmful.