Why do ISPs participate in the Copyright Alert System?

Why do the big five ISPs (AT&T, Cablevision Systems, Comcast, Time Warner Cable and Verizon) participate in the Copyright Alert System? They're going to have some disgruntled customers and may lose some business. So what's in it for them?

Online articles about CAS never seem to raise the question of incentives to the ISP, instead focusing only on how it's going to affect the end user. Ok, that's useful, but the incentives for a supposedly common carrier to anger customers are the more interesting part.

My best guess is that all five are providers of television, in addition to internet access. And probably studios told them the equivalent of, "If you don't implement this on your Internet side, you'll lose access to our content on your TV side."

Or is there another reason?

I'll also take this opportunity to point out that CenturyLink, my current ISP, isn't participating yet. Even though they provide television.

Job listings' priorities

Searching Stack Overflow Careers 2.0 for various skills, it looks like specifying a programming language is much more common than specifying a toolkit or framework:

• "wpf": 1 job
• "wcf": 1 job
• "entity": 0 jobs
• "swt": 0 jobs
• "javafx": 0 jobs
• "qt": 0 jobs
• "win32": 0 jobs
• "gtk": 0 jobs
• "cuda": 0 jobs
• "django": 8 jobs
• "spring": 7 jobs
• "c++": 34 jobs
• "java": 66 jobs

And looking through the language matches, it seems that many of them don't specify what frameworks or toolkits are in use. That's weird to me, because for me a language is easier to pick up than a toolkit/framework. (Objectively, some of these toolkits are way bigger than a mere programming language and its standard library.)

Plus, specifying a toolkit/framework is much more descriptive than merely specifying the language. When you see a job for "C++", you still have very little idea of what it involves. It might be server code, it might be a GUI program, or it might be an operating system. A bit less so for Java, but still Java is used in a wide variety of applications. But a choice of toolkit usually reveals a lot more.

Book review: Learn You Some Erlang For Great Good!

I've been aware of Erlang for almost a decade now. It's a programming language that's a pioneer in concurrency— created in 1986, before concurrency and parallelism were even a concept.

Impressed with Erlang's forward thinking, I tried several times to pick it up, but I couldn't get past the first few programs. When I got an opportunity to read and review Learn You Some Erlang for Great Good! published by No Starch Press, I jumped at the chance. The book is a printed and professionally edited version of the original free online book.

The first five chapters got me to write some basic stateless programs, useful to solve small problems. I found it very helpful that these first chapters provide comparisons to a procedural language that the average reader is used to — it's a comfortable baseline.

Chapters 10 and 11 explain how to write Erlang's equivalent of a class in procedural languages — a thing that has state in addition to behaviors. Erlang's version of this easily lends itself to running on a separate machine. With this functionality, I was able to implement an algorithm that features behind-the-scenes memoization. (That's the state.)

Later chapters introduce more advanced concepts that help me to think in Erlang and to write idiomatic code. For example, Chapter 15 describes a finite state machine design pattern. Another describes Erlang's way of propagating and handling errors. And so much more.

The author does a great job of introducing topics in a logical manner and without overwhelming the reader. Or maybe it's the comforting whimsical artwork that popularized the LYSEFGG style and flows through every chapter of this book.

As an Erlang novice, I have two complaints with this book. The first is, it doesn't discuss IDEs. I understand Erlang IDEs aren't as developed and polished as for other languages, but still — they exist. The book has you use a text editor combined with compiling your erl file by hand in the interactive shell. It's way less convenient than I'd like it to be.

The second complaint is that it doesn't mention the Erlang Debugger. Maybe in Erlang a debugger is less significant than in an imperative language, but it still seems worth a mention and some examples.

While I have a long way to go before I understand and know Erlang as well as I do other programming languages, after reading the first half of the book I feel significantly more at home with it.

(Thanks to O'Reilly Media for providing me with a copy for review.)

Market survey of proxies and VPNs

There are several reasons why one might want to be anonymous online, such as avoiding geolocation, writing emails without getting your personal IP address recorded in the headers, getting access to country-specific videostreams, and downloading copyrighted materials. Proxies and VPNs are technologies that promise anonymity, and there are many providers of them.

But which to choose? There are many online articles promoting one company's offerings or another's, but those articles aren't necessarily objective and don't tend to do thorough comparisons.

So I spent a few hours yesterday composing a market survey of proxies and VPNs. Right now I compare 25 plans of 12 companies.

My market survey is in OpenDocument Spreadsheet format. Open it with LibreOffice or Microsoft Office 2013. (I tried exporting it as PDF and HTML, but the results were pretty bad. And I don't know enough Javascript to create a web-based table that allows sorting by columns.)

I am not a subscriber to any (yet), but my top choice is Private Internet Access. It's one of the most comprehensive yet lowest-priced offerings. Plus their support is impressive: yesterday evening I emailed them with a question and got a reply less than an hour later.

I am happy to add more companies to the comparison, or to augment the comparison with additional columns. Just leave a comment.

Work-for-hire?

This is a question for fellow software writers. Suppose you're working on a project of your full-time employer. And you find yourself thinking about writing some code that's not strictly necessary, but would improve your project -- and be applicable to other projects.

Now the options are:

1. Don't write this code. It's not strictly necessary, and the program works fine without it.
2. Write this code exclusively for your project.
3. Write this code on your own time, package it as a library, publish it under a commercial-use-friendly license such as BSD, and fold it into the work project.

The employer would, without thinking too much about it, prefer either option #1 or #2. After all, why should they "share you" with anyone? Keeping your code proprietary yields a competitive advantage, doesn't it? Maybe.

But on the other hand, creating a open-source library would probably raise the quality of the result. Even if the employer ends up as the only user, the act of creating a separate library would force you to make a better API and cleaner code than if the code was tightly integrated with your project. If the library gains additional users, there may even be useful code contributions.

As an external library, now there is one place for bugfixes and improvements.

And because the library is developed on your own time (as it would have to be, for legal reasons), the employer gets a solution to their problem for free.

Now to see what my manager thinks of this.

Thoughts on airlines and the flying experience

Yesterday I came back from a trip to the west coast, flying two segments each way. I accumulated some observations and thoughts.

Passengers

1. When the seatbelt indicator turns off, half the people on the plane immediately unbuckle theirs even though they can't get up for a while longer -- as if the seatbelt is so unbearable that they can't stand it even for a second longer than necessary.
2. When the cabin door opens, most everyone with an aisle seat immediately stands (nay, jumps!) up, like they have someplace to be five minutes ago. Those with luggage quickly begin collecting it. Those without luggage simply stand with a purpose, intensely staring ahead. Then it takes another five minutes before the crew actually allows people to start walking out.
3. While waiting for bags, people want to stand as close to the baggage carousel as possible, even when there is simply not enough space for everyone to fit -- and when it's just as well to stand at a distance, give everyone room, and walk up just to collect your bag.

Don't smoke. But if do, here's an ashtray.

Annoyances about Airlines

1.  Airlines want to charge for checked baggage. But they also realize that people will start carrying more and more stuff onboard and there simply isn't enough room. So they allow you to check baggage at the gate, just before stepping onto the plane. It's free. And when you disembark, you just pick it up rather than walk to the baggage carousel. So why would anyone check baggage?
2. Airlines say they are all about safety, but they couldn't care less who sits in the exit rows. Flight attendants speak their schpiel about "if you cannot or are unwilling to perform exit row duties, please let us know," but don't actually care who's in the exit row. A few years ago my mom and dad happened to be in the exit row. The flight attendant leaned over to my mom and asked her if she's willing to assist if needed. My mom did not understand the question, gave the flight attendant a dirty look ("I don't know you, lady, so go away"), and turned away. The flight attendant seemed to be satisfied with that.
3. Some planes offer a "soothing sounds" music channel, inviting you to relax, close your eyes, and fall asleep to chirping birds and ocean waves. Great. Except that every music channel is interrupted when the flight crew decides to say something important like "The captain has turned off the seatbelt indicator." Good luck sleeping through an annoying announcement every five minutes.

 Suggestions for Airlines

1. Create an airport employee whose job it is to board the aircraft and stash passengers' baggage into overhead bins, Tetris-style. Once stashed, the employee leaves for another plane. That'll speed up boarding, reduce stress, and allow more baggage in the overhead bins.
2. Restrict exit rows to people truly able and willing to be useful in an emergency. Have an brief online training class, which registers you with the airline as "having passed exit row preparedness training."
3. Keep announcements brief and relevant. I don't care about the visibility and wind speed is at my destination city, the names of pilots, that the captain has turned off the seatbelt sign, that flight attendants should prepare for cross-check or takeoff (surely they have enough situational awareness to know this!), and especially that you wish to extend a special thanks to the United Premier Rewards members who are earning valuable points on this and other flights.
4. The "no smoking" indicator needs to be replaced by "no electronics" indicator. Smoking on aircraft hasn't been allowed for the last hundred years. But flight crew always bother to tell us when electronics are and aren't allowed. Just turn on the light. Better yet, allow electronics.

The evil command line

Compiling in the Windows command line with two parallel jobs, I saw this:

FFiinniisshheedd  ggeenneerraattiinngg  ccooddee

I can't help but imagine the computer hissing this at me while petting a black cat with a ring-studded hand.