Facebook as a machine of disinformation

One of the biggest problems on Facebook is that if someone posts misinformation publicly, and you reply, your friends are notified of the existence of the reply, but the primary information they get is the original misinformation. There is no way for friends to know that your reply was “This is false!”

This is one of the reasons a lot of misinformation is posted in images. (Another reason: it is harder to google text in images – you can’t copy and paste. That is why bogus quote attributions are often in images.)

If Facebook must post that “Fred replied to…” then it should either start with Fred’s reply, or it should not contain the original post.

(Then there is a problem with blatantly hateful posts. If you reply to those, you are spamming your friends with those hateful posts.)

Let Java do your work for you

I saw a lot of Java 6 code on a recent project that looked like this:

    InputStream input = null;
    try {
        input = new FileInputStream(...);
    } finally {
        if (input != null) {

This kind of thing really bugs me. The only reasons I can see for this type of code is:

  1. You are creating more than one stream object and don’t want nested try blocks. That seems like a failure in design.
  2. You are going to catch the IOException and re-throw a different exception. Here, you could create the object in a method rather than call new FileInputStream().

The better way for the simple case:

    InputStream input = new FileInputStream(...);
    try {
    } finally {

An experienced programmer who was new to Java asked, “but can’t new return null?” No, it can’t. Java’s “new” will never return null. It either returns the object created, or it throws an exception. (He still seemed dubious.)

Of course, Java 7 has the “try-with-resources” idiom, which makes this even easier, and it solves the above cases, as well. Rather than:

    InputStream input = null;
    OutputStream output = null;
    try {
       input = new FileInputStream(...);
       output = new FileOutputStream(...);
       ... do something with streams ...
    } finally {
       if (input != null) {

       if (output != null) {

You can write:

    try (InputStream input = new FileInputStream(...);
         OutputStream output = new FileOutputStream(...)) {
        ... do something with streams ...

which is much nicer.

I still feel like the “try-with-resources” syntax seems odd – it is unclear to me the best way to indent and space the code. It “smells like” a late addition to the language, in the same way that the new lambdas of Java 8 feel grafted on. Useful feature, but slightly inelegant.

“Wired” ad fail

Remember when “Wired” was cutting edge?

Here’s an ad on Wired.com as it displayed on my iPad.


Yes, they actually want me to see the ad only in portrait mode, and don’t give me the option to dismiss without the change in orientation.

Perversely, the ad was for a TV show, something you’d never watch in portrait mode.

Comcast Customer Service is the Worst

First, I find out I have to subscribe to a whole slew of sports channels to get access to Turner Movie Classics. But at least your website offers me that for an introductory price of $4.95 per month.

Then, when I order that package, I am called the next day and told that actually, the introductory rate is not available in my area.

When I ordered it at that rate, I was logged in. The fact that your web site engineers don’t know how to check if I am available wastes my time, and it wastes yours.

Congrats, Comcast. I’ll not be taking this new package.

Apple’s new single color icons look horrible

Apple’s iOS 7 has a number of “sharing” icons that look horrible. First, the “share” icon is now a square with an arrow out of it, that seems entirely unhelpful. But then the “Apple” icons that come up seem like horrible jokes or place holders. This is the “Share” menu inside Safari:


I think the fundamental misfire of iOS 7 is a misunderstanding of the human eye. The removal of skeuomorphisms I can get behind. But the human eye has evolved to use shadow and color to distinguish shapes. The removal of shadowing is not a removal of artifice, it is a removal of a visual clue for how to separate and interpret visual information.

Google Chrome preferences interface is insanely bad

Following recent news about flaws in Java, I decided to disable it in my browsers.

For Google Chrome, I couldn’t figure it out, so I found a web page that describes it.

The first thing that happens in you open preferences, which opened in a new tab (hiding the web page I was using as directions, nice.) Then you have to click three different things. One is blue text labeled “Advanced settings…” which expands as if displaying a previously hidden block of HTML. The next is a button, which displays a pop-up. The third is another piece of blue text, which opens another tab. And only then, are you presented with a list of plugins that you can enable or disable.

It’s not like there isn’t a lot known about how to do preferences in applications. Amazingly crappy, Google.

IPad Music App gripes – podcasts

It used to be the case that the iPad was great for listening to podcasts. You could quickly see which podcasts you hadn’t listened to, and you could play a whole bunch of podcasts at once.
I’m not sure when this changed, but nowadays, the interface doesn’t include any indicator of which entries you’ve already played, and no longer plays multiple podcast entries in order.
Finally, there is no way to access the longer description of a podcast, as far as I can tell.
Altogether, this makes listening to podcasts somewhat infuriating when you have a backlog. Say I have a backlog of ten “NPR Sunday Puzzle” episodes. I’d love to play them in order, but to do so, I have to start each on in sequence. By the time I get to the seventh, I have to remember which number I am on (since the interface gives me no clue which episodes I’ve watched.) in some cases, I can scan the titles, but, really, shouldn’t the interface be easier?
The failure to play podcasts in sequence automatically also makes listening to podcasts on a long drive impossible without either fussing with the iPad while driving oe stopping after every episode.
Maybe I’m missing something in the interface. I looked in all the places for preferences, but didn’t find anything.

Java interfaces and implicit contracts

While working on a project using Apache Flume to write data to Hadoop, we implemented our own Flume OutputFormat class to write compressed data in a particular format. What we didn’t realize was that the Flume OutputFormat interface came with an implicit contract.

The main interface method in an OutputFormat is:

  public void format(OutputStream o, Event e) throws IOException;

Now, the reality of the way Flume uses this interface is that it repeatedly calls the method on the same OutputStream with the same OutputFormat. For any period of time, the OutputFormat is only used with one OutputStream, and visa versa. For the lifetime of the OutputStream, it is only used with one OutputFormat object.

So you might think that you could buffer some output inside the OutputFormat. The problem here is that we only partially understood the usage of the OutputFormat interface in Flume.

In particular, Flume has an end-to-end reliability mode, which needs to know for sure if an Event has been written to a destination. If your OutputFormat buffers any data, then Flume has no way of knowing whether a particular Event got written to an OutputStream.

This means that any compression must be at best a per-record compression – the compression Codec must not have any buffered unwritten data when format() returns.

Interestingly, this was implicit in the interface, on some level – the fact that the format() method takes an OutputStream parameter would seem to imply that you shouldn’t buffer data. But the implementations generally assume the usage pattern above, keeping a reference to the current OutputStream for the duration. They just also did an internal “flush()” call which we tried to remove in our implementation.

See: https://issues.apache.org/jira/browse/FLUME-983

IMDB gripe – episode searches

One of the most common IMDB  use cases, for me, is: While watching an episode of, say, Law & Order, I wonder, “Who is that actor?”

If I go to the IMDB site, or use the iPad or Android app, a search for the episode title fails. I have to search for the show, navigate to the correct season (which is a guess, because I usually only know the year of broadcast,) and then browse the list to find the episode.

The workaround to this is to Google it. Add “site:imdb.com” to your Google search, as well as episode title and series name.

Another deficiency of the IMDB apps (but not the web interface,) is that if I find an actor, and his credits include, say, an episode of House, selecting that credit doesn’t take me to the episode, but to the House front page. That is hardly ever what I want.