I would put it this way: the fewer people use RSS, the better content providers can allow RSS to be.
But something else has happened over the past ten years; browsers got better. Their support for standards improved, and now there are evergreen browsers: automatically updating browsers, each version more capable and standards compliant than the last. With newer standards like HTML Imports, Object.observe, Promises, and HTML Templates I think it’s time to rethink the model of JS frameworks. There’s no need to invent yet another way to do something, just use HTML+CSS+JS.
Update: Read this excellent follow-up from Sam Ruby as well.
Tim Bray reviews the book of the year, Thomas Piketty’s Capital in the Twenty-First Century, and more importantly, rounds up the key reactions from around the Web. I’m very interested on the book, and I’m sure it will be on my “to read” list for a long time.
Here’s a question Paul Ford poses, and of course, attempts to answer in The Great Works of Software:
Is it possible to propose a software canon? To enumerate great works of software that are deeply influential—that changed the nature of the code that followed?
The list he comes up with is very solid. I feel like relational databases should also be represented — but it’s hard to pick one product. Should it be Oracle? It’s the first commercial relational database, and is still going strong. Maybe MySQL? They put relational databases in the hands of the masses.
It’s an interesting question to think about.
Every team and company has blind spots. In some cases, these blind spots can cut across an entire industry. One of the most common is Not Invented Here Syndrome, an inability to trust software that you didn’t write yourself. In the past, many businesses had a huge blind spot when it came to open source software, often going so far as to ban it as a matter of policy. These days, many newer companies refuse to purchase commercial software, preferring only open source software. These blind spots often lead to making the kinds of expensive mistakes that are also prohibitively expensive to fix.
Most often, blind spots result from a failure of pattern recognition. People see their own problems as novel when in fact they are slight variations of problems that have been encountered and solved many, many times. What got me thinking about this was a post by database industry analyst Curt Monash, who writes about his frustration with the many bugs and flaws he has encountered in online games that seem to result from a failure to use off the shelf database technology effectively. If there’s one thing we know how to do in the computer industry, it’s store and retrieve transactional data at scale, and yet it appears as though many game companies have absolutely no clue how you might build such a system.
The game industry is famously a monoculture, even by the standards of the rest of the software industry. It is also remarkably insular – there’s not a lot of crossover between working on games and working on other kinds of software. I’m sure there are plenty of people in the game industry who understand what relational databases are and how they work, but I suspect that the industry suffers from a lack of people who’ve built large-scale database applications that work reliably. More importantly, my impression is that the culture of the game industry would make it difficult to even hire people with that kind of experience.
How does a company minimize blinds spots? Obviously hiring for diversity (both with regard to demographics and experience) is a big deal, but the solution requires more than that. It’s also necessary to build organizations where people who point out blind spots are respected rather than ignored. In the example I’m thinking of, I’m talking about technology choices that lead to bugs and poor user experience, but the blind spot could just as easily be related to potential markets that go untapped, or management practices that lead to irreparable image problems and lawsuits.
The downsides of blind spots are pretty serious, and it’s not like my suggestions for preventing them are in any way novel or perhaps even interesting. So why don’t we do more to prevent them? To state the obvious, we’re rarely aware of our blind spots. More importantly, blind spots enable us to move faster thanks to the certainty they foster. They enable us to spend more time doing and less time thinking, and when you’re in a hurry, thinking often feels like a waste of time. Unfortunately, as we often see, they wind up being really expensive in the long run.
Solid piece on the big net neutrality sellout on the part of the FCC yesterday. Everyone is already writing about this, but I wanted to add my voice just in case decision makers are paying attention. Yes, we see what you are doing. Yes, we are mad about it. Yes there will be consequences in terms of votes, volunteerism, and campaign contributions.
Mike Bostock (the creator of D3.js) explains how he captures the steps to create a visualization using a Makefile. Amazing repurposing of an antiquated command. I might consider using something a bit more flexible, like fabricate, which enables you to write build scripts in Python, but the overall concept is fascinating and cool.
Everybody is probably already familiar with the Heartbleed bug in OpenSSL that was disclosed this week. I saw two explanations that really impressed me with their clarity. The first was Randall Munroe’s XKCD comic. In a few panels, it illustrates exactly what the problem is. The second is for those who prefer text, and was written by Rusty Foster, formerly of Kuro5hin, who did a great job of explaining Heartbleed in the New Yorker.
Brent Simmons wrote up one possible implication of the bug, which is that writing software in C is no longer worth the risk.
Recently rc3.org favorite Ta-Nehisi Coates got into a prolonged debate with Jonathan Chait (who blogs at New York Magazine) over whether it’s OK for Paul Ryan or Barack Obama to blame “black culture” for African Americans’ lack of economic progress relative to white people. Here’s Coates’ initial post if you want to start at the beginning.
Anyway, the debate shifts ground into an argument about whether Coates (standing in as a proxy for African Americans) should be optimistic and grateful for the progress that has been made on racial equality in America since slavery. Chait (who is white) argues that he should be, Coates disagrees. In doing so, he provides this quotation from Malcolm X1:
You don’t stick a knife in a man’s back nine inches and then pull it out six inches and say you’re making progress.
While it can of course be argued that African Americans are treated better today than they were 15 or 50 or 100 years ago, it’s also true that they continue to face pervasive discrimination as a matter of policy and custom. They owe America no gratitude for treating them less badly.
When there are obvious, structural problems black people face that are the direct product of historical and current discrimination, blaming black culture for lack of advancement is scapegoating. That much was clear to me after reading Coates’ argument. I’d encourage you to read back through his entire series of recent posts on the topic.
What occurred to me after I let the post sit on my brain for awhile was how broadly applicable Malcolm X’s quote is; not only to other social issues but in my personal life as well. For example, women in the technology industry owe men no gratitude for any progress that has been made on the gender inequalities, because the ledger is still far from balanced.
Today I started thinking about times when I realized that I was treating other people poorly and made an effort to change my behavior. Stepping away from my own perspective really made it clear that I was the person with the knife in Malcolm X’s metaphor. In nearly every case, I have believed that I was making progress, and expected not only gratitude but complete forgiveness for my past poor behavior, some of which no doubt continues.
When applied at the social level, the quotation in question is illuminating. Applying it at the personal level is humbling.
- Here’s a video of Malcolm X giving one version of this quote in an interview.
I’m really interested in Michael Lewis’s new book on high frequency trading, basically because high frequency trading is the kind of thing I hate, and I know Lewis hates it too. Felix Salmon throws some water on Lewis’s take, and argues that HFT is not as problematic as it’s made out to be.
My favorite article I recently read about HFT was Barbarians at the Gateways, a look at the technology behind HFT by Jacob Loveless. If nothing else, HFT is really, really interesting as a software engineering and systems design problem.