bryandunn.com

It’s rare I deal with any kind of MS product. On occaision, when I develop a UI one of the last steps I take is to “debug” it in IE, or work around the general IE idiocy issues. That’s about it. My Xbox 360 has worked well for the last several years but I don’t really do anything to exciting with it. I know the folks over at MS aren’t too sharp in the software design area, but they still never cease to astound me.

Today I signed up for Netflix again after a long hiatus. One of the things I was looking forward to was live streaming. I figured I’d just use my 360 to stream. So here’s how the process went:

1. Start my Xbox, which auto-signs me into my current Silver membership
2. Navigate to the netflix icon, which prompts me to download the netflix streaming app
3. Download the netflix streaming app and start it
4. I’m informed that I need to upgrade to a gold membership to stream netflix
5. I try to upgrade my account from the xbox and I get a “8015d080″ error, which leads me here. Turns out the Windows Live ID’s expire after a period of inactivity. Evidently, logging into your xbox live account does not count as “activity.”
6. I find out that you can sign up for a new Windows Live account, then transfer your gamertag to the new account via the Xbox Live dashboard. Great!
7. Sign up for the new Windows Live account, navigate to the “Change my Windows Live ID” option and I’m greeted with “Can’t connect to Xbox Live. Please retry later.” I’m already signed in mind you.
8. Google a bit to find out others have this problem and they had to go through MS Support to resolve it.
9. Send an email to support (the form on the xbox support page doesn’t work correctly either – maybe just in firefox, or firefox on Linux – the dropdowns don’t update when you change topics from “hardware issue” to “Xbox Live issue”. I’d guess the chances of my email getting to the proper support place are roughly 1/1,364).

If I had the choice of taking a job programming in .NET, Silverlight, etc or eating out of the garbage, I’d be dumpster diving in no time.

Update: Spoke with MS support over the weekend and as I suspected I had to create a new gamertag with my new Live account in order to upgrade to the Gold membership.

Last year at this time I took a Java programming class as a refresher as I hadn’t done much with Java since my days as an undergrad (and a few short programs in grad school). After primarily using Perl for the last 7 years, this was a big switch. The difficulty with Perl is that it’s a programming language for concenting adults. You can do almost anything any number of ways. The amount of time it takes to understand a block of Perl code is far greater than that of a block of a statically typed language like Java. This had been a huge issue for our company as we had tons of legacy code that followed no standard.

It is my firm belief that if you are going to develop a large codebase in Perl, you MUST use a fairly stringent coding standard. In my first week in my current role, I came across three separate “subroutines” that were over 2500 SLOC. One of the shorter subroutines had 200 SLOC and 32 regular expressions. 4 of these regular expressions were over 80 characters long. Dynamic subroutines are often used. Map statements that turn arrays into hashes are the norm. One library that I maintain is > 10000 SLOC and contains 7 comments. It has been my personal nightmare for more than a year and a half now.

Some of this has to do with simply not understanding best development practices regardless of language, other things (like not adding a comment for a 120 character regular expression) could have been avoided by the use of a coding standard. 80% of software development is maintenance, plan accordingly. One way to force yourself to do the right thing when writing code is to pretend the guy who is going to be asked to maintain it is completely psychotic and knows where you live.

In any event, I have found that using a stringent coding standard is far less important when using Java because:

• it’s statically typed – I know what I’m going get back from any subroutine. I don’t have to worry about using Data::Dumper with die statements to figure out what complicated object I’m dealing with.
• you can use a debugger – no more running the entire program and relying on print statements to figure out what’s going on. I can see the value of each variable and I can make changes on the fly and see the results. This is a huge timesaver.
• frameworks – although there are a few frameworks for various paradymes in Perl, Java takes the cake here. It cuts down on development time by allowing developers to concentrate on the functionality of their application instead of the middleware that must accompany it. Using a framework (struts, spring, hibernate, etc) also makes it trivial for all developers to understand how a module works.

I can’t understate the huge amount of time our company has saved since switching to Java. “Estimated Time to Fix” is greatly reduced and more work is accomplished.

I spent roughly 6 hours Sunday trying to fix the wrong bug. Long story long:

Due to a problem with the timezone on one of our database servers, the last two time changes caused several issues. Among them, a message from our mail software claiming we were trying to schedule a mailing for a time in the past. Even though once a mail is scheduled, the mail system simply queries the database and sends all mailings that have a scheduled time in the past. Evidently the initial creator of our mail system wrote this check into the scheduler to ensure he wouldn’t encounter any issues if he ever got around to inventing a time machine. On Sunday, the day we set our clocks ahead, when the error popped up again, it was obvious that the fix we made 6 months ago didn’t work.

5:30 – phone call from C trying to send a mailing reporting the error

5:30-6:00 – spent time verifying that every single machine I could think of that possible touched this process had the proper time set (they did)

6:00-6:30 – pulled in a systems engineer to verify the same thing I just did (and he did)

6:30 – process restarted since all the times had been verified with the ‘notify_delay’ time set to 61 minutes to account for the hour difference

6:32 – C notices there is a configuration variable (mail_on_reprocess) that must be set to allow a re-processing to send out the mailing. We decide to wait for the current process to finish, then rerun with the proper configuration.

7:15 – re-processing finishes, C notices there is a mailing scheduled despite the bad config – oh well, we’ll take it. C resets the configuration to defaults to avoid future problems.

7:35 – mailing completes, C notices the mail has sent to 0 recipients instead of the 4200 it should have

8:15 – after scanning the code, I notice that a mailing is created even in the event the mail_on_reprocess variable isn’t true, it just sends it to 0 recipients. Fuck.

8:30 – C sets the re-processing variable and re-runs

9:15 – re-run complete, we see the timing error again. WTF?

9:15-9:45 – Rethink my strategy, find that the code generating the schedule date gets the time from the database server, not the local machine unlike our other mailing code that was working fine all day. Obviously, I was right in assuming the database was off even though it reports back ok. Must be a timezone translation thing that happens in the Perl DBI module.

9:45 – re-run, set notify_delay to 61 minutes, mail_on_reprocess to true

9:45 – 10:30 – drink, shower

10:30 – failure again, bad config, unrelated issue

10:30 – 11:57 – re-run twice more. C has been awake for 21 straight hours at this point.

11:57 – 11:59 – check mailing is scheduled and sent to proper number of recipients

Turns out the timing problem had nothing to do with the time change, and the fact that it generates the same error we see whenever the clocks change is a mere coincidence. It had to do with the fact the schedule date is calculated BEFORE the list of recipients is generated, which took 40 minutes. With the delay set to 30 minutes, we’ve moved past the schedule date and only Doc Brown can get us back.

Coincidences:

• this process results in the same error we see whenever the clocks change
• the clocks changed that day
• unlike all of the other code that sends mail, which was working, this method got the time from the database server and NOT the machine’s local time, fueling the idea that the database server’s time was the culprit
• this was the first time since the code’s release 6 months ago that the recipient creation time ever took longer than the notify delay

Took my first delve into google charts today and it was the balls. Gathered a bunch of data and had google charted it for me, all in less than an hour. Needed to find the number of occurrences of a problem one of our logging facilities was having per day and figure out if they had been declining since I made a change last week. I already had a script to give me the number of occurrences per day, so all I did was:

• use awk to give me a comma separated list of data points (187,138,163,88,90,203,235,131,140,67,137,83,131,156,89,220,291,140,22,21,422,103,179,113,383,84,134,193,141,86,194,74,148,242,240,368,94,186,20,20,170,223,114,40,21,315,53,56,125,155,140,30)
• set the chart type: cht=lc (line chart)
• set the size: chs=600×300
• set what axes to display: chxt=x,y
• set what labels to display on the axes: chxl=0:|Nov|Dec|Jan|1:|0|250|500
• set where to display the labels: chxp=1,0,50,98|0,0,40,84
• set the dimensions: chds=0,500

I ended up with this:

http://chart.apis.google.com/chart?cht=lc&chs=300×300&chxt=x,y&chxp=1,0,50,98|0,0,40,84&chxl=0:|Nov|Dec|Jan|1:|0|250|500|&chds=0,500&chs=600×300&chd=t:187,138,163,88,90,203,235,131,140,67,137,83,131,156,89,220,291,140,22,21,422,103,179,113,383,84,134,193,141,86,194,74,148,242,240,368,94,186,20,20,170,223,114,40,21,315,53,56,125,155,140,30

I spent an hour trying to figure out what a field in a fixed width file was being truncated by one character. This is what I found:

Definition

<header start=”1″ end=”8″>accountnum</header>

Calcuation

$length = $header->{end} – $header->{start}

Great, except that columns 1 THROUGH 8 total 8, not 7. Ugh.

Interesting article on Agile/Scrum development process:

http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

This took me a few hours to figure out so I’m logging this here for my own sanity. If you have a bidirectional many-to-many mapping in Hibernate with a join table, the join table is only updated when the noninverse side of the mapping is inserted/updated. In the example below, the join table (pane_specs) is only updated when a spec is saved, not when a pane is saved:

Spec.java

@ManyToMany
@JoinTable(
name = “pane_specs”,
joinColumns = { @JoinColumn(name = “spec_id”) },
inverseJoinColumns = { @JoinColumn(name = “pane_id”) }
)
public List<Pane> getPanes() {

Pane.java

@ManyToMany(mappedBy = “panes”)
public List<Spec> getSpecs() {

Interesting post at O’Reilly about Perl and how some companies view it as the major problem behind legacy applications. Obviously false but it just goes to show that Perl should be “used by consenting adults” with some semblance of adherence to standards.

http://www.oreillynet.com/onlamp/blog/2008/08/why_corporates_hate_perl.html

I’m currently maintaining a production application that has given me headaches since I started. It is less than two years old and meets all of it’s requirements, but it’s lack of maintainability has it slated to be rewritten in the next few months. Despite several subroutines that are more than 2000 SLOC I’ve sort of begun to understand the way it is written and how to more quickly make edits to the code. At times it’s made me question my troubleshooting skills but now that I am less frustrated by the app, I’m beginning to wonder where in the development cycle it failed. For all it’s flaws, it does it’s job. Yet it’s a far higher priority to rewrite it than it should be given it’s age and production record. The issue is it takes a long time to make changes and most changes cause unwanted side effects.

First off, there are obviously some general engineering issues that plague this app (note the large subroutines). I’m going to ignore those because although textbook examples of poor engineering practice riddle this app, it should still be clear what the intent of a block of code is. This is the first place it fails: NO COMMENTS. Ignoring all the other problems, if the app was commented it would be 75% easier to maintain and would not require a rewrite so soon.

It seems obvious to me why code comments are a good thing, but I’ve heard arguments against them. The most common is “good code comments itself.” I read a great counterpoint to this from Jef Raskin. Comments not only tell other developers what the code does but why:

A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique

Thanks Jef! I would also like to note that it takes far less time to read and understand a block of code than to read a single line comment that explains what the block does. It at least helps identify if this block is the one you are looking for or if you should keep going.

The second major problem kind of falls in line with the first. Evidently there were not any design specs or requirements written for the application. The only thing that is left here is talking to the original stakeholders and trying to figure out what the initial specs were and digging through the many thousands of lines of code to figure out exactly what the current app is doing. Obviously, there isn’t a very good chance that the requirements (the initial ones or what the app has evolved into) will be reconstructed with any degree of exactness.

All I can think of is my first semester in Computer Science when we were all told the worst thing to do when writing an app the worst thing to do is open your IDE and start coding. Turns out they were onto something.

Much to the dismay of many standards proponents, the OOXML office standard passed the fast track International Standards Organization (ISO) vote last week. For anyone reading this that doesn’t know what this was all about here’s a quick rundown:

Despite the dominant market postion held by Microsoft, some companies had started moving away from using Microsoft Office due to the fact that MS office document formats are proprietary, tying users to MS office. Because of the outcry for open standards, MS decided it would be good to show consumers they are committed to playing nice with everyone else and use an open standard. Of course, there already exists an open document standard, ODF. The problem with using the ODF format for MS is that other products who already use it would suddenly become viable alternatives to the MS office suite. Instead, they proposed their own format, Office Open XML (OOXML).

In true Microsoft fashion and to no surprise of their critics, the OOXML specification was around 10-times larger and infinitely more complicated than the existing ODF format. Despite the problems with this document, Microsoft was able to work “around” ISO rules,  and buy/strongarm enough votes to get the specification to pass. A long list of irregularities in the ISO voting process can be found here.

Here’s what sucks:

1. Knowing a single company has enough power to pull this off. It makes me skeptical of all politcal processes.
2. Once again, a company with questionable (at best) business practices and a dominant market position wins. In an ideal world, objectivity would enter into these decisions somewhere.
3. A single company (with a history of exploiting their dominant market share to make it difficult for competition) will now control an entire ISO standard.
4. This vote showed some serious flaws in the ISO organization that will likely weaken it’s power and encourage countries to adopt their own standards instead of relying on a newly corrupt international entity.
5. As the world seemed like it was getting smaller and working better together than ever before, we revert to allowing a single corporation to decide what is good for us.

Perhaps this is a weakness of capitalism or a call for reexamination of business (and ISO) standards. Either way, it’s discouraging to see an entity with only it’s best interests in mind pull off something of this scale.