LateNightHacking Louis Journal

Auth

For those who liked the badgers, here's another one: The Duel

I called my Grandpa today to wish him luck on his big surgery. He's going in for bypass surgery on Wednesday. We're all rooting for him.

I finished helping Monica reverse engineer and rewrite an old file parsing tool she had to support. This thing had some incredibly bad snippets, and it was only 200 lines! How about this one:

    String buf;
    protected void nullit() {
        String s = "no";
        String s1 = "";
        for (int i = 0; i < buf.length(); i++) {
            if (i == 0 && buf.charAt(i) == '"') {
                s = "yes";
            } else if (i == 0) {
                if (buf.charAt(i) == ',') {
                    s1 = s1.concat(" ");
                    s1 = s1.concat(buf.substring(i, i + 1));
                } else {
                    s1 = s1.concat(buf.substring(i, i + 1));
                }
            } else if (!s.equals("yes") || buf.charAt(i) != ',') {
                if (s.equals("yes") && buf.charAt(i) == '"') {
                    s = "no";
                } else {
                    if (buf.charAt(i - 1) == ',' && buf.charAt(i) == ',') {
                        s1 = s1.concat(" ");
                    }
                    s1 = s1.concat(buf.substring(i, i + 1));
                }
            }
        }
        buf = s1;
    }

Never mind the vague method name, never mind using strings for booleans, never mind using a global buffer, never mind the convoluted logic - it's run time is O(n²)! Times m lines! I don't think you can use String in a worse way. (Hint: if you find youself in this situation, use StringBuffer. Strings are immutable. In the above, a new String was built for every letter in the original String.) I'm pretty sure this method was taking up all of the 40 min required to execute the entire process.

I like this one too:

                StringTokenizer stringtokenizer1 = new StringTokenizer(buf, ",");
                for (int k1 = 0; stringtokenizer1.hasMoreTokens() && k1 < 3;) {
                    switch (++k1) {
                    case 1: // '\001'
                        s = stringtokenizer1.nextToken();
                        break;

                    case 2: // '\002'
                        s1 = stringtokenizer1.nextToken();
                        break;

                    case 3: // '\003'
                        s2 = stringtokenizer1.nextToken();
                        break;

                    default:
                        k1 = 4;
                        break;
                    }
                }

                StringTokenizer stringtokenizer1 = new StringTokenizer(buf, ",");
                s = stringtokenizer1.nextToken();
                s1 = stringtokenizer1.nextToken();
                s2 = stringtokenizer1.nextToken();

                StringTokenizer stringtokenizer1 = new StringTokenizer(buf, ",");
                if (stringtokenizer1.hasMoreTokens()) {
                    s = stringtokenizer1.nextToken();
                }
                if (stringtokenizer1.hasMoreTokens()) {
                    s1 = stringtokenizer1.nextToken();
                }
                if (stringtokenizer1.hasMoreTokens()) {
                    s2 = stringtokenizer1.nextToken();
                }

It just makes you proud to be able to stand up and say, "I didn't write that." :)

˜ ™

At work, risk integration is still a contentious issue. We spent probably at least an hour talking about it after today's group meeting. All that needed to be said was that we're not sure what the requirements are and we need to work on it in a future working session. We still ended up discussing what the requirements might be and platform we should be using and whether Sailfish's user authentication model is worse than Risk's (which is highly amusing because neither really has one).

There just don't seem to be any clear answers. My personal suspicion is that what we want is not just a report generator / viewer, but a "calculation form" generator / viewer. What they've got is Excel, which they use because it's powerful and open-ended. They don't like it because multiple version maintenance is difficult and it's slow. Now, as Dan said, "I don't know of any language in which you can't write a slow program." There is some chance that improving their development process could yield improvements. It just feels like they don't want any of the advantages of moving away from Excel enough to give up any of the advantages of using Excel. Hmm.