I feel obliged to comment since I responded to the original news of his arrest with a somewhat sardonic post called “When Ethicists Steal.” (Swartz was a Fellow at the Harvard University Ethics Center and the title referred to my long-held suspicion that self-styled academic “ethicists” just come up with rationalizations for their gut feelings and present them as scientific results, far superior to the ethical opinions of mere mortals.)

Swartz downloaded a vast number of academic articles from the JSTOR database. He apparently believed that they should be freely available to the public. Who knows? Maybe he was right, given that the public probably paid for the research with their tax dollars.

However anyone with any involvement with computers should understand that it is not OK to enter a network wiring closet without permission in order to make an unauthorized connection to the network. Surely this would justify some sort of criminal penalty.

On the other hand what he did was in no way comparable to murder. It was more on the level of entering an empty house though an unlocked door and taking a sandwich from the refrigerator. Except that nobody was deprived of a sandwich. (JSTOR, the aggrieved party, didn’t lose any money and didn’t want to press charges.)

So the loud outcry that the federal prosecutor was abusing his power by threatening to send Swartz to prison until he was an old man is not without merit. We have lost a bright and promising young man whose actions were surely misguided but not evil.

On the other hand we are not dealing with a rogue prosecutor here. This is what prosecutors do every day, though usually not to people with so many friends in the media. They routinely threaten to send people to prison for the rest of their lives in order to pressure them to plead guilty to reduced charges–even if they are innocent. That’s the kind of justice system we have and presumably that’s the kind of justice system the voters want, otherwise they would change it.

Now she has something to say that probably none of us want to hear: There’s Little We Can Do to Prevent Another Massacre. Unfortunately I suspect that she is right.

Tell me that you haven’t heard this one before:

• To begin with, you have a CEO who is a great visionary. (Everyone tells him he is, so he must be.) He doesn’t know much about Information Technology, but that’s OK–you can hire people to handle that.
• The CEO is approached by an IT consultant who proposes a great new system, something that has never been done before, which will run rings around the competition.
• The consultant has never actually developed a system of comparable complexity but the CEO is impressed with his vision. He tells his people to give the consultant everything he needs.
• Because of the great strategic importance of the project the team accepts an extremely aggressive development schedule. It just has to be ready by the drop-dead date. To make it work the team will have to put in lots of overtime and not waste too much time on things like design reviews and extensive testing.
• The consultant creates an elaborate marketing presentation to sell the project to the organization (and maybe to outsiders as well.)
• To simplify the transition they decide on a “Big Bang” implementation. On the deadline date the old system will be irreversibly shut down and the new system will go online.
• Users are given “training” that is basically a rehash of the marketing presentation. They can’t practice with the new system because it isn’t ready yet.
• Result: Profit! humiliating failure.

Even this doesn’t necessarily get to the heart of the problem. I’ve seen projects fail even though they came in on time and under budget with all the required features, just because the original specification didn’t match what the organization really needed. You need to understand the problem before you come up with a solution.

Suppose Orca had worked perfectly as designed. Poll watchers would have used their smart phones to submit real-time reports to the giant computer in Romney’s Orbital HQ. The computer would have analyzed the data and issued real-time orders to field workers via their cell phones.

The most likely result would have been that Romney would known a few hours earlier that he needed to write a concession speech. (As it was, with Orca flopping helplessly on the beach, his team was reduced to watching the TV news broadcasts and found out the results at the same time the rest of us did.)

Any experienced campaign manager should know that you need to have your resources in place before Election Day. Any scheme to dynamically shift resources around while the voting is taking place is likely to have very limited effect.

So the correct way to manage this particular project would be not to do it at all. Instead it would have been better to spend those millions on opening more field offices and providing better training for volunteers.

That would probably not have been enough to change the outcome of the election. Nate Silver’s final analysis of the results makes it clear that the situation was beyond the ability of any get-out-the-vote drive to salvage. However they should have at least been able to flip Florida which would have made the final result less embarrassing.

“Orca” was the campaign’s massively-hyped centralized computer system for managing the get-out-the-vote drive. It was supposed to track the process in real time and shift resources as necessary from areas where Romney was running far ahead to areas where more help was needed–thus running rings around Obama’s more old-fashioned system.

In fact the system was inadequately tested and users had essentially no training. On Election Day it collapsed, leaving the campaign managers flying blind. Given the margin of victory this probably wasn’t enough to change the results the election. (The “ground game” is supposed to be good for a point or so.) Still, it certainly didn’t help.

“The end result,” Ekdahl wrote, “was that 30,000+ of the most active and fired-up volunteers were wandering around confused and frustrated when they could have been doing anything else to help. The bitter irony of this entire endeavor was that a supposedly small government candidate gutted the local structure of [get out the vote] efforts in favor of a centralized, faceless organization in a far off place (in this case, their Boston headquarters). Wrap your head around that.”

• A slow count or recount in which we won’t know the outcome for several weeks. (Think 2000).
• An “Electoral College inversion” in which one side wins the popular vote and the other side wins the Electoral College. (Once again, this happened in 2000.) This is bound to cause resentment on the losing side.
• A 269-269 tie in the Electoral College. In that case the House of Representatives chooses the President and the Senate chooses the Vice President. The House is pretty certain to remain under Republican control while the Senate is pretty certain to remain under Democratic control, so we will end up with President Romney and Vice President Biden. That will be embarrassing to say the least.

On the other hand it is still barely possible that we will have a clear winner soon after to polls close on the East Coast.

In any case, most states are not competitive so the winner in the Electoral College will be determined in a small number of swing states where the race in considered close. If you keep an eye on the swing states you will know the outcome as soon as anybody does.

States where the polls close at 7 PM ET

Florida. Romney seems to be holding on to a comfortable lead, which is good for him because without Florida he’s toast. There is no plausible winning combination for him without the state’s 29 electoral votes.

Virgina. This state looks very close and potentially vital. Whoever gets VA’s 13 electoral votes will have a very big advantage.

States where the polls close at 7:30 PM ET

North Carolina. Probably belongs to Romney but Obama has made a significant effort. Still, if Obama takes NC it probably means that the polls are wrong and he’s going to win easily.

Ohio is where the election is most likely to be decided. To win without Ohio’s 18 electoral votes, Romney would probably have to sweep all the tossup states (CO-IA-WI-VA-NH) while Obama would probably need 4 of them. Obama seems to have a small lead here, but if it comes down to a close race here we may be waiting a long time to know the winner.

Over a quarter of a million people have already voted by absentee ballot and these will not be counted until Nov. 14. (A ballot mailed on Election Day is allowed up to a week to arrive.) Both sides have hordes of lawyers and spin doctors ready to descend on the state if the count is close enough to justify a manual recount.

States where the polls close at 8 PM ET

Michigan. Obama is favored to win the state’s 16 electoral votes, at least partly thanks to the auto bailout.

New Hampshire. First, forget Dixville Notch. It doesn’t mean anything. Most scenarios leading to an Electoral College tie require Romney to take NH. Otherwise the state’s 4 electoral votes probably won’t be decisive.

Pennsylvania. Obama is favored to win here but the Romney campaign has made a significant effort. It is just possible that the aftereffects of Hurricane Sandy might depress turnout enough to give Romney a boost. If Romney were to get PA’s 20 electoral votes that would turn the race around, making it difficult for Obama to come up with a winning combination.

States where the polls close at 7 PM Mountain Time or 8 PM Central

Colorado. a close race with 9 electoral votes.

Wisconsin. Another close race and 10 electoral votes. Assuming that we know who won Ohio at this point, either CO or WI would be in a good position to wrap things up.

States where the polls close at 7 PM Pacific or 9 PM Central

Iowa. If we’re still paying attention at this point the race will be very close indeed. A toss-up state with 6 electoral votes.

Nevada. 6 electoral votes which will probably go to Obama (plenty of Mormons but even more Hispanics.)

Sources

I have relied heavily on 2 sources: Larry Sabato’s Crystal Ball site and Nate Silver’s FiveThirtyEight.

Larry Sabato uses a fairly straight-forward average of polls, combined with his expertise as a long-time observer of U.S. politics.

Nate Silver uses a more complex and controversial mathematical model which combines polling and economic data. Polls are weighted to compensate for “house effects” (some polling firms consistently seem to favor Republican or Democratic candidates) and for differences in methodology (polls that include cell phones get more weight than those that call only land-lines.) He then runs tens of thousands of simulations every day, slightly varying the assumptions for each iteration. This allows him to assign ridiculously precise probabilities to various outcomes.

This approach allowed him to correctly predict the winner in 49 out of 50 states in 2008, but as they say, past performance is no guarantee of future results. For what it is worth, these are some of the probabilities calculated by his model as of Sunday Nov. 4:

Obama wins the Electoral College: 85.5%
Obama wins the popular vote: 50.5% 80.1%
Romney wins the popular vote but loses the Electoral College: 7.3%
Obama wins the popular vote but loses the Electoral College: 0.7%
Electoral College tie: 0.2%
Recount (one or more decisive states within 0.5 percentage points): 8.3%

To get the updated version, go back to my original aLinks post.

The Register: Don’t download that app: US presidential candidates will STALK you with it.

But the winner of the incompetent-design sweepstakes has to be Dollar Rent-a-Car, who asked me for the last four digits of my driver’s license number and my birth date for verification (but not my old password). Then, when I clicked “Change Password”, it took me to a customer-support e-mail form! Apparently I was expected to type a message asking a human to change my password for me. I declined; it seems monumentally stupid for them to let one of their employees to have access to thousands of customer passwords. Instead, I used the form to ask them to let me know when they deploy a secure system.

Observations on changing passwords

The key Java classes are as follows:

java.util.TimeZone

This is an abstract class that contains the definition of a time zone, including that zone’s rules for Daylight Saving Time (or what Europeans refer to as “Summer Time.”) Any code that needs to explicitly deal with time zones should use a TimeZone object.

The best way to get a TimeZone is to call the static method TimeZone.getTimeZone() and pass it the standard “Olson name” such as “America/New_York” or “Pacific/Honolulu”.

This link lists all the standard time zone names.

You can call TimeZone.getTimeZone(“GMT”) or TimeZone.getTimeZone(“GMT-5″). None of these GMT-based TimeZone objects support Daylight Saving Time. (Note: “GMT” and “UTC” mean practically the same thing. GMT is defined in terms of astronomical observations and UTC is used for setting atomic clocks. For most practical purposes they can be treated as identical.)

You can also use common abbreviations e.g. TimeZone.getTimeZone(“EST”) instead of TimeZone.getTimeZone(“America/New_York”). This is strongly discouraged. Depending on circumstances you might get the wrong Daylight Saving Time behavior or even the totally wrong time zone, since the same 3-letter abbreviations are used around the world for different time zones.

When displaying a time zone to the user you should probably call TimeZone.getDisplayName(). Depending on the parameters you pass this will return a user-friendly value like “Eastern Standard Time”, “EST”, “Eastern Daylight Time” or “EDT”.

java.util.Calendar

This is an abstract class which serves as a wrapper around two independent values:

• A time, stored as the number of milliseconds since January 1, 1970 00:000:00 GMT.
• A TimeZone object which indicates how the time should be displayed.

(This is an oversimplification. The actual implementation is a a bit more complicated, but this is close enough as long as you are not actually digging into the source code.)

Note that the time offset is always supposed to be in GMT. If you see code samples that make a different assumption (and there are many out there on the web) ignore them.

Time zone conversions are simple: if you call setTimeZone() on a Calendar object you get the exact same time but displayed in the new time zone.

A more complex problem occurs when you get a time string from a user in a different time zone. If you parse the string “05-01-2012 08:35 AM” then the parser will generally give you a Calendar object for 8:35 AM in the computer’s default time zone.

If this is wrong then you will need to change the time offset to convert it to the correct time. If the time string was supposed to be in GMT then you can use the folowing code to convert it.

public static Calendar convertToGmt(Calendar c) {
    java.util.Date date = c.getTime();
    TimeZone tz = c.getTimeZone();
    long timeInMilliseconds = date.getTime();
    int offsetFromUTC = tz.getOffset(timeInMilliseconds);
    Calendar gmtCal = new GregorianCalendar(TimeZone.getTimeZone("GMT"));
    gmtCal.setTime(date);
    gmtCal.add(Calendar.MILLISECOND, offsetFromUTC);
    return gmtCal;
}


If it was supposed to be in a different time zone then you can call TimeZone.getOffset() for both time zones. The difference between the two values will give you the number of milliseconds that you need to add to do the conversion.

This code provides an alternate way to convert between arbitrary time zones.

public static Calendar convertToNewTimeZone(Calendar calendar, TimeZone timezone) {
    Calendar newCal = new GregorianCalendar(timezone);
    newCal.setLenient(false);
    boolean am = newCal.get(Calendar.AM_PM) == Calendar.AM;
    newCal.set(Calendar.YEAR, calendar.get(Calendar.YEAR));
    newCal.set(Calendar.MONTH, calendar.get(Calendar.MONTH));
    newCal.set(Calendar.DATE, calendar.get(Calendar.DATE));
    newCal.set(Calendar.HOUR, calendar.get(Calendar.HOUR));
    newCal.set(Calendar.MINUTE, calendar.get(Calendar.MINUTE));
    newCal.set(Calendar.SECOND, calendar.get(Calendar.SECOND));
    newCal.set(Calendar.MILLISECOND, calendar.get(Calendar.MILLISECOND));
    boolean ampm = calendar.get(Calendar.AM_PM) == Calendar.PM;
    if (am && ampm) { // cal = 0 but we want 1
        newCal.roll(Calendar.AM_PM, 1);
    } else if (!am && !ampm) { //cal = 1 but we want 0
        newCal.roll(Calendar.AM_PM, -1);
    }
    return newCal;
}


Once again, this gives you a Calendar object with the same wall-clock time in a different time zone, as opposed to getting the same actual time in a different time zone.

ISO 8601

To avoid such problems when sending dates and times between different time zones you can use the ISO 8601 formats commonly used in XML documents. These formats allow an optional trailing time zone indicator e.g.

2012-05-01T08:35:01.123Z
2012-05-01T08:35:01.123-05:00

A “Z” code indicates that the time is GMT. A “-05:00″ indicates a time zone that is 5 hours behind GMT. In the U.S. this could mean either “Eastern Standard Time” or “Central Daylight Time”.

Most standard XML libraries can handle these formats.

In the “-05:00″ example above the parser will return a Calendar subclass whose TimeZone object is “GMT-5″, not “America/New_York” or “America/Chicago”. You have the correct time but you don’t really know which official time zone it is.

The time zone indicator is optional. If the document contains

2012-05-01T08:35:01.123

that will be interpreted as being in the receiving computer’s default time zone.

java.util.Date

This is a wrapper around a count of milliseconds since midnight January 1, 1970. There is no associated time zone.

According to the documentation the millisecond count should always be in GMT, but this is often ignored. You will find many code samples on the web that attempt to deal with time zones by adding or subtracting hours. This is NOT recommended.

If you need to deal with time zones you should use a Calendar object.

The Date class has methods like getHours() and getMinutes() which are all deprecated. If you use them they will return the value in the computer’s default time zone. Date.toString() will also display in the computer’s default time zone.

java.sql.Date

This is intended to represent a SQL DATE field. The Java implementation is a simple wrapper around java.util.Date which makes sure that the time part is always set to midnight in your computer’s default time zone.

What is actually stored in the database depends on the implementation but can be assumed to consist of a year, month and day in some format.

java.sql.Time

This is intended to represent a SQL TIME field. The Java implementation is a thin wrapper around java.util.Date which makes sure that the date part is always set to January 1, 1970.

What is actually stored in the database depends on the implementation but can be assumed to consist of either an offset from midnight or a combination of hour, minutes and seconds in some format.

There is no support for time zones built in. If time zones are important the application will have to keep track of them separately.

java.sql.TimeStamp

This intended to represent a SQL TIMESTAMP field. The Java implementation is similar to java.util.Date in that it contains an offset from a fixed starting time, but it is much higher precision, supporting fractions of a microsecond instead of milliseconds.

What is actually stored in the database depends on the implementation but is usually some sort of offset from a starting date.

TimeStamp is similar to java.util.Date in that

• It does not contain a TimeZone.
• The internal offset is supposed to be in GMT and bad things can happen if it is not.
• It is typically displayed in the computer’s default time zone.

Usually you create a TimeStamp from a java.util.Date object. (If you are starting with a Calendar object just call getTime() on it.) So basically you are writing out the millisecond offset in the GMT time zone. If you started with a Calendar its original time zone is lost.

When you read a TimeStamp from the database you are getting back the time with no time zone information. Calling getDate() will return it as a java.util.Date object. If you want it in a time zone other than your computer’s default time zone you can do something like this:

Calendar cal = new GregorianCalendar(desiredTimeZone);
cal.setTime(ts.getDate);


A lot of the value in Apple has come from the ineptitude of other companies and the passion and willingness of early adopters to spend huge money. There are inherent limits to growth fueled by those two factors. For example, the early adopters with the greatest willingness to pay for smartphones (and associated service) have already purchased smartphones. Now the big market is from people in emerging countries, such as China, and the average consumer in developed countries. The record companies were so poorly managed that they gave up 30 percent of their digital music revenue because they were too lazy to run their own Web site. What other industry is going to give Apple 30 percent of its revenue in exchange for Apple running a server?
Philip Greenspun–Apple will decline after Steve Jobs…