Flash card Friday

I have started this habit of writing down lessons I learn on flash cards. I try to get one card written every day, with at least one item on each card. Every Friday I will now try and publish that week's insights. My comments may range from technical stuff about coding and networking, to more general insights about everyday life. Now, some of you might say, this is common sense, or, that's soo obvious. I don't care. Even if you don't learn anything, it's always good to reiterate. If you think I'm wrong about something you should definitely comment. That way, at the end of the day, at least one of us will be enlightened.

So here's the first list:

• Don't start efforts without a plan
  
  Sometimes it's very tempting to just get in the saddle and get going. Problem is, if you're not sure about where you're going, why should you go at all? This applies to coding as well as general planning. It is so easy to waste time doing things that you really don't know why you are doing, or that you don't know that you actually will need. The Pragmatic Programmer refers to this as programming by coincidence. When something is planned poorly, resources are easily wasted. You know that uneasy feeling when things are slowly gliding out of your control? Watch closely for that feeling, because it indicates that something is wrong. Do you know why are doing what you are doing?
  
  
• When in doubt, zoom out
  
  The previous bullet sort of relates to this one. When you feel that you are questioning what you are doing, and can't get the nitty gritty details to fit together nicely, zoom out. Take a step back and ask yourself and your colleagues, what are we actually doing? Why? Is there a simpler solution? If you can't get things to fit nicely, and feel that you must incorporate some kind of "hacks" to get your solution working, then you are probably going down a bad road. Forget the details, take a deep breath, ask the big questions. Hell you might even realize that you don't need this thing at all.
  
  
• Java 5 can't compile method calls on return values from methods returning bounded wildcard types
  
  Given the following pseudo code:
  
  class Base {
    public void bar() { ... }
  }
  class Zoo {
    public E foo() { ... }
  }
  Zoo z = new Zoo();
  
  Trying to compile the following line with Java 5 would yield a compile-time error:
  
  z.foo().bar();
  
  This is sort of stupid, because the object returned by foo() will always be a Base object (or a subclass of Base), so it should be able to perform the compilation. I don't know what actually happens at bytecode level though, but I'm guessing invokevirtual will be used. Java 6 will however compile it fine. A good way of avoiding this problem is to never use generics in public API return values. It just makes it complicated for the user to use, and doesn't really add any extra functionality.
  
  
• PECS
  
  PECS stands for Provider Extends, Consumer Super. It's from Effective Java, 2nd Edition, and it states the rules for when one should use extends and super with bounded wildcards. It only applies to method arguments, as wildcard types should not be used as return types. If a method argument produces data for the method to use, then the argument should be defined using extends. If it instead consumes data that the method feeds it, it should be defined using super. Google for more details.
  
  
• ip helper-address + ip directed-broadcast enable forwarding of broadcast packets to another network
  
  If you need to extend the broadcast domain of one network to another, it is possible. This might be useful is a service is broadcasting messages on a local network, and devices at a remote location need to listen to those messages too. Using Cisco equipment, this can be achieved by first sending the broadcast traffic to the other network by using the ip helper-address command, and then re-broadcasting it there by using the ip directed-broadcast command. You can control which ports are forwarded by using the ip forward-protocol udp 12345 command, which now will only forward port 12345. A hack? Yes. Potentially useful? Yes.
  
  
• Java's -classpath does not work with -jar
  
  I guess it's a well-known fact, but I didn't know it. When running a JAR file with java -jar file.jar, you can't specify any class path arguments to the JVM. Either the class path must be defined in the manifest file, or the JAR file must be added to the class path via command line and the application launched via the main class on the command line. Anybody have an explanation for this behavior?
  
  

Stay tuned for next week's lessons learned.