Book review: Programming the Mobile Web

"Mobile web" is vast landscape. It has always been fragmented, with standards bodies pulling one way and browser developers trying to ignore them and do their own thing—whether to stand out or to get that new release out the door quicker. A developer who wants their web site to work and look good on a wide variety of devices had to either be as conservative as possible (1990s-era HTML tends to look the same everywhere), or to buy a room full of mobile devices for testing.

With Programming the Mobile Web, the author Maximiliano Firtman put his roomful of mobile devices through their paces. For designers, the book explains what can be done on today's devices. For developers, it explains what protocols and file formats are supported on which devices, what screen resolutions to expect, how to query for capabilities, and how to gracefully degrade functionality when certain features are not available. The coverage of protocols and file formats is impressive, going all the way back to WML and covering all the way up to HTML5, CSS 3, and modern Javascript libraries. It also covers HTML5 new features, including local storage, geolocation, and improved media support.

Reading this book, you may feel like you're getting mentoring from a long-time, grizzly web developer who's been deep into it from the very beginning. An example of a bit of wisdom from the book:

When you load an image in a web application, the original file size matters only in the data transfer. Once the file is on the browser, it is decoded in memory and it is always treated as a bitmap. Therefore, the size in memory can be calculated as width × height × bits per pixel. We should be careful, therefore, about loading big image files even if they are small in terms of bytes. Just to give an example, a full-screen image on a third-generation iPad will typically use around 12 MB of RAM.

Using more RAM will impact website performance when loading, scrolling, and returning from a frozen state (for example, when changing tabs).

Obvious? Maybe, in retrospect. As a programmer, I've known that graphics chips and low-level rendering routines don't deal with PNG, but rather with bitmaps that occupy RAM. But I didn't apply this knowledge to mobile web until reading this. This book has more than its share of these.

However, this is not a programming book per se. The best way to treat this book is as a companion to web programming books like the classic JavaScript: The Definitive Guide. Programming for Mobile Web will tell you what to be aware of across a wide swath of devices to ensure a consistently reliable and pleasant user experience, and it'll guide you to make good design decisions. Then once you know what you want to do, programming books will see you through the implementation.

Programming the Mobile Web How do you take advantage of the new opportunities opening up in mobile web development? With this book, you'll learn the intricacies and pitfalls involved in building HTML and CSS-based apps that you can extend to work with particular devices, including the iPhone, Nokia, Blackberry, Android devices, and other smartphones. You'll not only learn how to deal with platform variations, finicky browsers, CSS compatibility, and other issues, but also how to create pleasant user experiences in a constrained environment.

O'Reilly's one-day massive sale

As you may know, I am a big fan of O'Reilly Media, a premier publisher for technical literature. I am a member of their Bloggers program, giving me an opportunity to read new ebooks and review them. I am also a member of their affiliate program, giving me a small cut if you buy anything through the below link.

Today, O'Reilly is having a massive sale on ebooks, in celebration of the Day Against DRM. O'Reilly, along with many other ebook publishers, had at one point made the difficult decision to not use any Digital Rights Management on their ebooks. This is a massive win for the consumer, and only an arguable win for the publisher, so I am grateful to O'Reilly for doing this.

The sale lasts today only!

Check out the multitude of technical books and videos and learn something new today!

Mac or Windows?

My new employer wants me to choose between a 13" MacBook Pro and a Lenovo machine running Windows. (That's all the specs I have.)

I've never used a Mac, beyond my brief, awkward experiences in tech stores where I try to interact with a Mac, get frustrated with how unusual things are, and walk away. (And this is after using Linux on the desktop for 10 years and leaving for Windows' greener pastures.) But the incredible popularity of MacOS X  -- and the neverending stream of defections from Windows -- is strong evidence that the Mac is worth learning.

Should I take the plunge, or should I stick with Windows?

This would be for web development, with actual development being on remote Linux servers. The machine would interface with the servers using sshfs or Samba.

Browsers should open the .md file extension

Inspired by this comment, I propose that web browsers should open and render the md (Markdown) file extension the same way browsers already support html, jpg, and many other file extensions.

Book review: Vintage Tomorrows

You may have heard that any movie based on a novel is forced to gut the novel to the bone in order to fit within the allotted time. You may have also read interviews by screenwriters, directors, and producers that it's a very challenging and painful task. The authors of Vintage Tomorrows have spared themselves. Vintage Tomorrows is 412 pages long. By god, I read at least the first third. I really tried to get into it. But after a while, I couldn't take it anymore.

Vintage Tomorrows sets a goal of defining steampunk. A relevant quote:

"A steampunk object arrives with the intention that it’s not meant to be used when it comes out of the package. You’re meant to do stuff with it… to make it yours. It has to be sized to fit. Stuff has to happen to it. It’s meant to be bodged and changed after it arrives. You can see how it’s been put together. It has obvious snags hanging off of it where you’re meant to add stuff, or fix stuff, or attach stuff, or even move stuff around." --a certain Cory

What an appropriate way to describe this book! The book is a cornucopia of the authors' musings on day-to-day minutiae, on their experiences and thoughts in local restaurants, on the most trivial details of numerous conversations that are presented, unsummarized, in their full glory. This is the closest to a stream of consciousness that I've experienced since reading House of Leaves many years ago. I can see how the book has been put together. But I don't buy a toothbrush where it's my job to attach the bristles.

Needless to say, I haven't figured out the point of the book. I hope it's simply that I don't see eye to eye with the authors.

Preventing filesystem traversal attacks

I am implementing a software feature that takes a filename from a client and accesses it on the server. The filename is supposed to be a simple filename, not a path. The server appends the simple filename to a predefined absolute path to access a file of the user's choice within a specific directory. (Symbolic links are not an issue.)

But of course, the client can send any filename whatsoever, exposing the server to a filesystem traversal attack.

Initially I had hoped that Boost::Filesystem would have a bulletproof solution. This module is already sensitive to the operating environment; it changes its behavior depending on whether it's on a POSIX-compatible system or Windows. I was hoping for something like path::contains_upward_traversal() or path::is_simple_filename(). But no such luck.

Instead, I cobbled together the following:
using boost::filesystem;
path p = get_untrusted_filename();
bool p_is_name_only = !p.has_root_path() && !p.has_parent_path();

Here's my test set:

hello	is name only
he/lo	reject
/	reject
.	is name only
..	is name only
/hello	reject
/../../../hello	reject
../../hello	reject

I have not found a way to combine path accessors to eliminate the dot and double-dot while still permitting a simple filename. But fortunately, those two false positives point to a directory. If you add Boost's is_regular_file(path)to the mix, only the simple filename gets accepted.

Another option is POSIX's realpath, which we can use like so:
#include <stdlib.h>
#include <limits.h>
char abs_path[PATH_MAX];
realpath(p.string().c_str(), abs_path); //check ret val

Now if p contains an absolute path, abs_path will contain the same absolute path, with relative traversal collapsed. If p contains a relative path, abs_path will contain an absolute path starting from the application's present working directory.

Lastly, to verify that the client's given filename is within the trusted directory, simply check whether abs_path starts with it. Any attempted traversal would cause this check to fail.

In my case, the client is trusted anyway, so this is a case of gold-plating. If the client was truly hostile, as would be true for public-facing servers, I would certainly consult a security specialist and do further research. But this suffices.

Is there an existing library for guarding against filesystem traversal attacks, or an improvement to what I have?

720p is irrelevant for Microsoft?

I have a laptop running Windows 8. It has an HDMI port. I've used this laptop to watch Netflix content using the Silverlight plugin and display it on my 720p projector. Normally it works fine.
But yesterday streaming was laggy; the video wasn't flowing as smoothly as the audio, and the two would get out of sync. Firefox's plugin container was meanwhile using 100% CPU.

So I thought, I am running Windows 8. I want to watch Netflix. Netflix offers an official Windows 8 app. Maybe it's higher quality than the browser plugin. So I fired it up, and...

On my home 720p projector.

At first I cursed out Netflix. But then I recalled that Microsoft imposes a minimum screen resolution for Metro-style apps. Sure enough, the minimum is 1024x768, while my projector — and any 720p TV, which is still very common — is a measly 48 pixels too short.

720 is a worldwide standard resolution, and is one of only two HD resolutions, the other being 1080[p].

So Microsoft chose to exclude a very large set of displays by increasing the minimum resolution by just 6.7%. But apps are supposed to support many resolutions anyway.

I can't imagine a not-antiquated desktop monitor with a resolution below 1024x768. On the laptop side, netbooks were pretty much defined by 1024x600. I can understand Microsoft not supporting such a small height; it's quite inferior to 768. But ignoring 720 while promoting the new app ecosystem? A mistake.

I bet Netflix is not happy with this.

Remove your email signature

Has the following ever happened to you? You write an email that asks two questions, and you get a reply only to the first. Or you send someone an informational email, talk to them afterward, and realize that they missed the last paragraph. This happens to me more frequently than I like.

I have a hypothesis. People miss the end of my emails because I don't have an email signature. They're so used to ignoring a block of text at the end of an email that my actual content is collateral damage.

So, for the good of society, I propose for everyone to remove their email signature. When it's there, you as the reader simply ignore it.

I've seen signatures that list the sender's phone numbers. I've seen signatures that include quotations from famous people. (At times, quotations from the sender that the sender believes are dripping with brilliant wisdom.) I've seen multi-paragraph signatures that raise a storm in a teacup about not disseminating the email without permission and deleting the email immediately if you're not the reader. In a particularly egregious case, I've seen a photo scan of someone's business card used as the signature. Actually, scratch that. The most egregious case is signatures that contain the sender's email address. Holy shit.

It's tempting to have a signature just in case someone wants—nay, needs!—your fax number. You may have been told by a well-meaning parent or significant other that a signature gives a professional appearance. Heck, you may have added a signature just because everyone else has one.

And why not? We don't pay by the word for email. Except it's not free. You're decreasing the value of your communications. You dilute your main point with a block of text that has absolutely nothing to do with it.

Worse, it signals to your reader that you value their time so little that you're going make them read a block of text that's guaranteed to be irrelevant. I don't take kindly to that.

Remove your email signature. Remove noise. Show your readers that you value their time. Make your content stand alone. And you ever doubt this decision, just ask: WW^SJD?

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.

Businesses, start accepting Dwolla

It's a panicky feeling when you reach into your pocket to pay for something and realize that you forgot your wallet! This happened at least twice to me in the last few months. I almost never forget my cell phone, though.

And just now I read about a lawyer who spent the night in jail because he forgot his wallet and couldn't pay his $208 restaurant bill. He had his cell phone with him, though. I dread becoming the next victim.

This brings me to: businesses, get with the program and start accepting mobile payments!

Oh, but the landscape is changing so quickly! Are any of mobile payment services any good yet?

Yes. Dwolla is good. It's like PayPal, but with significantly lower fees and better integration with banks. Money transfers are free for transactions under $10, and a flat 25 cents otherwise. Aside from training your staff on this new system, there's literally no downside. It's cheaper than credit cards, secure, instant, and works great when a customer forgets his wallet!

 Dwolla?! Why would I go with some no-name?

Let's talk alternatives. How about the Near-Field Communication (NFC) methods that are in vogue now? Well, these require special hardware. Very few phones support this now, and it seems unlikely that more phones will start supporting it in the future. The latest phones don't. Additionally, there's a battle going on between Google and Verizon, with both trying to start competing mobile payment systems. It's a mess. The point is, the biggest problem is that NFC requires special hardware both on the merchant end and on the customer's end, which means cooperation of many entities.

The easier approach is to require merely a smartphone and an app. Dwolla and PayPal fall into this category. Be a good merchant and accept both! PayPal is on par with credit card companies when it comes to transaction fees. Dwolla, on the other hand, is committed to low overhead costs. That's its biggest draw for me and many others. It's the only mobile payment system that allows transactions at near-par value! Cash is king. Checks clear at par value, but are inconvenient for both parties. Dwolla is mobile, safe, instant, and almost free. Revolutionary!

Whether you're a merchant or a consumer, consider joining the revolution. We need more people on both sides of the equation. If I inspired you to look into Dwolla, use my referral link to join and get $10 in credit.

If you live in Coralville or Iowa City, the Electric Beach Tanning Salon accepts Dwolla (thanks to me) and even offers a limited-time discount if you pay with Dwolla or cash.

Why not store files on the desktop?

I just read the article An Irrational Fear of Files on the Desktop, where the author James Hague argues that a desktop is a fine place to store files: it is part of the filesystem, after all, and your files are "in-your-face." Those are good points.

My mom sometimes forgets where she saved her files. That's another good reason for newbies to store files on the desktop. Windows makes the Desktop appear as the root node in the filesystem graph -- at least when browsing using Windows Explorer. (Click "Up" enough in the File Open or File Save dialog, and you end up at the Desktop.) I haven't decided whether I agree with that decision.

So why not store files on the desktop? (To clarify, this is a discussion about how to guide casual computer users, not experts.)

Corporate IT tends to not synchronize desktops between computers, whereas My Documents tends to be synchronized / shared. For example, at Rockwell Collins, when I log into a new-to-me computer using my enterprise credentials, the desktop is impersonal and is locally-generated. It has some program shortcuts, but none of my personal files or shortcuts. My Documents, on the other hand, points to the network-attached-storage with all my files. This also means that if the computer's hard drive dies overnight, desktop files are gone forever.

At first I thought it's a shortcoming of Rockwell Collins' IT. After all, Windows allows synchronizing the desktop just like My Documents. But then, like with many things, experience revealed the reason. As the IT administrator for a local private school, I thought I would do things "right" and synchronize the desktop for teachers between computers. It worked beautifully, from the technical perspective. I sat back and felt proud of myself. Then complaints started rolling in.

What I didn't think about is that most programs by default make a shortcut to themselves on the desktop. These program shortcuts are synchronized across computers just like files; Windows makes no distinction. (Why not? The Great Raymond Chen explains.)

Is the problem clear now? Say the IT administrator helpfully synchronizes the desktop. When a user logs in to a new-to-him computer, he sees the desktop shortcuts to all the programs he installed to his other computer. He tries to launch them.... what, Windows cannot find the program? What the hell? The computer's broken!

It is difficult for a casual computer user to understand that just because the shortcut is there, the program isn't. That requires a surprisingly sophisticated understanding of the filesystem and the independence of the desktop from Program Files.

In the case of my private school, after getting enough complaints and having to explain over and over again, I turned off the policy that synchronizes the desktop. This also means that if a computer user stores a personal file on the desktop, it stays local. Only the user's My Documents are visible on another computer. This setup detracts from the "seamless" cross-computer experience I was hoping to achieve, but this is much easier for a casual computer user to understand.

The root cause of the problem seems to be that software installers seem to treat the Desktop as not a place for personal file storage but as a list of installed programs. No installer has ever offered to create a program shortcut in My Documents, but every installer wants to create a shortcut on the Desktop, Start Menu, and/or Quick Launch. (That's also the reason not to synchronize the Start Menu between computers.) In other words, semantically it's understood that My Documents is for the user's personal files. The desktop is semantically for anything and everything.

Is this really a good enough reason to avoid storing files on the desktop in general? After all, home users don't need to worry about corporate IT synchronization policy. Well, it's a matter of habit. Users will do what they're used to. If a user is used to the desktop being the dumping ground for all files, he'll do the same on his corporate desktop.

And that's why it can be better to store personal files only in My Documents.

What's the best (computer) mouse?

For two years now, I've had a mouse at home with side buttons. I've never used those buttons until very recently. One of them is the equivalent of "Back." I immediately fell in love with this button. At work, however, my mouse is spartan: no side buttons. My thumb keeps reaching for "Back" and not finding it. Now I want a new mouse.

What do you recommend?

I'll gladly entertain off-the-wall peripherals like the AlphaGrip and Handykey. (They're a keyboard + mouse.)

Book review: CLR via C# by Jeffrey Richter, 4e

There are many books on C#. But there are few on the CLR, the runtime that runs compiled C# code as well as some lesser-known languages like F# and languages I wish were lesser known like Visual Basic.

CLR via C# takes you on a tour of the entirety of CLR. The book is not meant as casual reading. It covers a lot of material and is quite in depth.

I've written a few rather basic WPF-based programs in C#, but I don't yet have a significant interest in the CLR. This book did not perk up my interest in the CLR. I tried reading this book from the beginning, but soon realized that it's much more suitable as a reference. You experience a problem, decide to learn all you can about an area of the CLR -- trust that this book will have enough information. As a casual C# programmer, I have learned some new things from this book, but only as far as I've forced myself to read. That's my biggest problem with the book; even for a deeply technological book, it doesn't appear to try to motivate the reading. "Here's a firehose; drink up." Putting it down evoked a sense of relief.

So, get the book if you have a specific CLR-related goal in mind, or if the CLR is your primary way of making a living. For example, if you want to learn everything about CLR garbage collection, this book will tell you.

If you're a casual C# developer and just want to understand the CLR better, a few MSDN articles may be more appropriate; this book can too easily become too much.

(Thanks to O'Reilly for providing the ebook for review.)

The Lying Disease

A fascinating article, The Lying Disease by Cienna Madrid.

And my favorite comment from there: "Most of the crimes we commit against each other are not illegal." It applies to way more situations than it ought to.