No Open Blockers

It’s hot as hell in my office. I’m on the third floor of a townhouse and have virtually no air circulation in here, so if I turn on anything more than a laptop it starts to generate a rainforest climate. Needless to say, my open computer isn’t helping things. So rather than take steps to properly alleviate the situation, I added another hack to the mix.

The worst part is that there is a showing for the house tomorrow, so at some point today I have to actually man up and make this place presentable.

And yes, I do see the irony in posting a picture of a giant box fan pointed at a half assembled computer under the category “technology”.

Remember being a kid on Christmas? Diving through an endless sea of presents as wrapping paper and cardboard packaging fluttered in the air like snow. And how once it all settled, your parents would not let you play with your shiny new toys until after you’ve cleaned up the disaster.

A few days ago I posted about my sweet desktop memory upgrade. Installing the new chips took maybe 10 minutes, and then another hour or so of debugging timings and what not (which at times required me to reset the BIOS using a jumper on the motherboard itself). Once I got that to a (reasonably) stable state, I’ve been cruising in full 8GB glory.

This was on Sunday.

Today is Friday.

This is what my office currently (read: still) looks like:

The moral of the story? If mom and dad hadn’t made me put down the shiny new toys and clean up, the wrapping paper would have become a permanent decoration in the house.

Picture courtesy of Lolcats.

Yes, I know it drifts over into my sidebar. Just 100 more pixels would make this theme so much nicer.

We just finished covering data types in class, including a pretty in depth look at the Java Collections libraries. The book covered the basics, but there are a few concepts I wanted to touch on that may be helpful in the upcoming project.

Java can automatically sort collections for you, provided you tell it how to. There are two ways to do this:

Comparable
Unlike equals and toString, which are provide by the Object superclass, the compareTo method is optional. Classes may choose to provide a description of how to compare instances of that class by implementing the Comparable interface. That interface contains a single method compareTo(T o) that provides a numeric result indicating if the object on which it is called is less than (result is less than zero), greater than (result is greater than zero), or equal to (result is zero) the object passed into the parameter.

For instance, for a rather generic Person class, the following implementation would provide sorting based on the person’s last name:

1
2
3
4
5
6
7

class Person implements Comparable<Person> {
  // Attributes
 
  public int compareTo(Person other) {
    return this.lastName.compareTo(other.lastName);
  }
}

Note the use of generics in the implements clause. This lets us write the compareTo method to explicitly take a Person instance rather than the generic Object, saving us from having to deal with the casting. Also note that in many cases, the compareTo method (like equals and hashCode) will often chain down to a simpler data type’s Comparable implementation, in this case String.

One benefit of this approach is that the class is self-describing. In addition to describing how to compare two instances for equality, the class also describes how to order instances of the class. The drawback to this inclusion is that it’s a single method of sorting. There isn’t a really clean way in this approach to distinguish if the person objects should be sorted by last name or, say, social security number. That’s where the second approach comes in.

Comparator
Similar to Comparable, the Comparator interface contains a single method that returns a numeric result. However, a comparator is meant to be a separate class from the one being compared (whereas the Comparable interface is meant to be used by the class being compared). As such, the compareTo method takes two arguments, meant to be the two objects being compared.

For instance, we could write the same ordering functionality as above in an external Comparator implementation:

1
2
3
4
5

class PersonComparator implements Comparator<Person> {
  public int compareTo(Person p1, Person p2) {
    return p1.getLastName().compareTo(p2.getLastName());
  }
}

Again, the use of generics allows us to write the compareTo signature using specific classes rather than just Object references. Note that this implementation is outside the Person class and thus doesn’t have the same access to private variables that the Comparable implementation uses. This shouldn’t be a problem, but it’s worth noting.

There are a number of conventions in the collections APIs to make life easier. For instance, almost all collection classes contain a constructor that takes a Collection as a parameter. That constructor will populate the new collection with the entities in the parameter. For instance:

1

List newList = new ArrayList(oldList);

Keep in mind this doesn’t do a deep copy of each element in the old list. It simply adds all of the object references in the old list to the new one. In other words, the first item in each of these two lists will refer to the same object. However, they are different lists and one can be manipulated without affecting the order or contents of the other.

This is often a good approach when returning collections from a method call. It can prevent the caller from mangling a collection internal to another class, as well as prevent the caller from holding an open iteration of the collection, preventing the original owner of the collection from making any changes to its contents.

This is also a way to jump between different collection types. For instance, if you have a list that may contain duplicate items that you want removed, you can easily throw the items of the list into a set, which will automatically remove the duplicates in the process:

1
2

List hasDups; // Initialized elsewhere
Set noDups = new HashSet(hasDups);

The same functionality can often be achieved through an addAll(Collection c) method that many collections provide. This method will do exactly that: add all elements from one collection to another:

1
2
3

List oldList; // Initialized elsewhere
List newList = new ArrayList();
newList.addAll(oldList);

There are other handy features, such as the ability to make a collection thread-safe or constants for empty collections, that I won’t go into just yet. This has already been more of a wall of text than I like to make these sorts of entries.

1
2
3
4

-> cat /proc/meminfo 
MemTotal:      8196508 kB
MemFree:       7473284 kB
...

The sweet, sweet smell of hardware upgrades. I bumped my home Fedora 10 x86_64 desktop to 8GB this weekend. That is, I did it after digging through a good 1/4 inch of dust to actually find my memory slots first. In my next home office, I’m not having carpet, this just bites. That, or a fanless machine, but I digress.

Why did I upgrade? The better question is why not. It’s still running DDR2 which these days they pretty much give away in happy meals and at the bottom on cereal boxes, so it’s not like cost was really a problem. More importantly, this will help feed my growing (arguably unhealthy) obsession with seeing how many virtualized guests I can have running on my network at the same time…

Just came across the following:

1

sa.setRemainingTries(new Long(10)); // hmm 10?

Not sure what the issue is with using 10 here, but for some reason it invoked the image of The Thinker.

I’m not looking to get into a big discussion of what virtualization is, so I’ll steal a quick summary from wikipedia:

In case of server consolidation, many small physical servers are replaced by one larger physical server, to increase the utilization of costly hardware resources such as CPU. Although hardware is consolidated, typically OSes are not. Instead, each OS running on a physical server becomes converted to a distinct OS running inside a virtual machine. The large server can “host” many such “guest” virtual machines.

Ok, that reads a little bit complicated. I have complete Red Hat Enterprise Linux 5 (RHEL 5) installations running from inside of my Fedora desktop as if they were all on their own machines by themselves. They connect to my internal network just like any other machine, getting their own IPs and being able to connect to my Spacewalk server running downstairs in my family room. From the network point of view, it can’t tell the difference and looks like I have a ton more computers in my house. That’s a good thing, since with the warm weather coming the single desktop I have in my office is enough to generate a small tropical climate as it is already.

Pictures don’t do justice to how cool looking this is. I use a dual monitor setup, so a fullsize screenshot would end up at 3360×1050, just a bit bigger than the annoyingly thin fixed width theme I have on this site (seriously, once this semester ends and I get back some free time, this shit has to change). However, I’ve done my best to capture the total awesomeness of my desktop right now. Click the image for a larger-but-not-fullsize version.

That’s two RHEL 5 installations running on top of Fedora. The terminal is SSHed into one of them, so I don’t actually have to use the GUIs.

The coolest part is that it was dead simple to set up. I used two links, the first for the majority of the installation and the second for the bridge configuration to the network:

• Techotopia Installing and Configuring Fedora KVM Virtualization
• Libvirt Wiki: Bridged Networking