rc3.org

Strong opinions, weakly held

Author: Rafe (page 32 of 989)

Why GitHub matters

Most days I think Git is the worst tool I use, but I don’t feel the same way about GitHub. John Norman explains why GitHub is really important:

Today, the announcement of a new project would happen by a number of means, but the beginnings of the code project would exist at GitHub. GitHub puts the social exchange at the very center. I suspect that GitHub’s servers now contain the world’s largest corpus of commentary around intellectual production. As I see it, the production of code has been wildly accelerated since the advent of the open source model; but the emergence of GitHub has been like throwing gasoline on that fire.

Read the whole thing.

The downside of working on free products

Fred Wilson has a post up today defending companies that have advertising-supported business models. I’m not opposed to free services, I use and enjoy a large number of them. Unlike the majority of users, though, I usually pay when I use a service that offers a paid tier. I pay for Rdio, a Flickr Pro account, a Mlkshk account, and probably others as well.

As a developer (or designer) who’s looking for a job, though, I think that working on advertising-supported products has some real downsides, because doing the right thing for your users and doing the right thing for your advertisers is often in conflict.

Trying to gather more data to offer more value to advertisers rather than customers is not appealing. Figuring out how to design your site so that users see more ads doesn’t sound like fun, either. There are compromises to be made in every business, but to me the compromises involved with balancing the needs of advertisers and end users seem really painful.

The further problem is that nearly all advertising-supported companies start out without a fleshed out revenue model, burning cash and trying to rapidly grow the user base. Then at some point they have to implement a business model, and the changes that necessitates often lead to massive user unhappiness. That’s not a pleasant proposition, either.

There is value in adapting to the world

When I was younger, I was obsessed with the following maxim from George Bernard Shaw’s Maxims for Revolutionists:

The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

That quote sprung to mind when I read this post by Sam Stephenson where he explains why he doesn’t invest too much effort in his dot files. Here’s the key bit:

What I discovered is that in many cases, my ability to adapt to a foreign environment without frustration is more important than the benefits of configuring a local environment to suit my whims. And that being able to quickly recreate my environment from scratch is an asset.

I fall more into Stephenson’s camp than I do into Shaw’s at this point, at least when it comes to my own tools. As software developers, we are trying to build things that adapt the world to ourselves, but with experience, I find it more and more important not to bind myself too tightly to any particular tool or process.

Skip the organic, read the labels

Today’s New York Times has a long article about organic foods, more specifically, about how the FDA-approved “Certified Organic” designation has been co-opted almost completely by industrial food producers, diluting it to the point of meaninglessness. This does not come as a surprise to me. As soon as “organic” became an adjective that people would pay a premium for, it became inevitable that corporations in the food business would want a piece of the action. Now they’re busily diluting the definition of organic so that they can more easily adapt it to their industrial production methods.

Beyond doing things like going to the farmer’s market and buying food from the producers themselves, I have another trick for buying “whole foods” whether I’m at Whole Foods or any other grocery store. I read the list of ingredients. If it has ingredients that I don’t recognize, or don’t seem to belong in whatever it is that I’m buying, I skip it. Sometimes I wind up buying mass market brands, sometimes high end “organic” foods, and sometimes it’s store brand.

The first time I tried this approach was buying honey mustard. I was shocked to find that most of the honey mustards on the shelf didn’t even contain honey, most of them instead contained high fructose corn syrup and lots of other weird ingredients that I don’t recognize. I finally found a bottle of mustard that had a list of ingredients that included ground mustard, vinegar, and honey, and no strange ingredients we don’t have in the cabinet at home. To get back to mass market brands, French’s Mustard is delightfully simple (and awesome).

I realize that familiar ingredients can be produced in unpleasant ways, but there’s a limit to what can be practically achieved in our modern society. The best favor you can do for yourself if you’re not going to restrict yourself to food you or people you know grew is to stick to reading the labels.

Can you judge someone by their shell prompt?

Tom Ryder on shell prompts:

You can tell a lot about a shell user by looking at their prompt. Most shell users will use whatever the system’s default prompt is for their entire career.

Should we be asking job candidates for their dot files?

What The Well is all about

Veteran Well member Howard Rheingold has a nice piece up about the significance of The Well, which has been around for almost three decades and is looking for a new home now that Salon has put it up for sale. It’s amazing the number of features people take for granted today that were proven on The Well. More importantly, the closeness of the Well community is difficult to accurately describe. It’s amazing to see long lost members returning over the past couple of weeks to offer help or just to reacquaint themselves. For what it’s worth, I think that the two current communities that are most like the Well are Reddit and Metafilter.

The leap second bug

Nelson Minar has a nice, short writeup of the Linux kernel bug that caused servers to spin out of control yesterday. Most initial write-ups blamed Java, but that was incorrect. Interestingly, Java not only accounts for leap seconds, but also mentions them prominently in the documentation for the java.util.Date class:

Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a “leap second.” The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.

As Nelson notes, time is complicated. Further evidence of this fact is provided in Noah Sussman’s post Falsehoods programmers believe about time and his followup.

PHP’s hidden strength

It’s easy to complain about PHP. Look, here’s Jeff Atwood complaining about PHP. He proposes to create something that will replace PHP. I’m all for this project — as an industry, we should constantly be working to improve and replace things, and we should be building great things in case they do wind up becoming popular.

If you’re going to try to replace PHP, you need to figure out what it is about PHP that enables it to maintain its massive market share. Everybody knows about the friendly learning curve and the easy availability of inexpensive hosting. If you want to create your first Web application, PHP is the simplest way to get started.

What’s interesting, though, are the reasons why you see some of the biggest Web sites deployed on PHP. It’s not because developers love it. It starts with the fact that PHP is easy to operationalize at any scale, or at least easier than most other technologies. It doesn’t require an app server, or a virtual machine, or anything that’s outside the realm of basic Unix processes.

What’s more important, though, is that many of the most experienced ops people in the industry who have deployed large scale sites have a PHP background. They understand how PHP works and where it fails. Building that experience on a different stack would take the same thousands of hours that they’ve already invested in learning how PHP scales. It also seems to me that you see less scaling-related drama from PHP-based sites than you see with sites that try newer technologies, or eclectic mixes of technologies. We’ve never seen Facebook go through growing pains like Twitter has gone through.

If you’re working on something with the goal of displacing PHP, the Twelve-Factor App manifesto is not a bad place to start. The other option is to build something that runs on top of the JVM, because there’s a lot of operational expertise in that area as well.

That said, the simplicity of PHP from an operations standpoint and the deep experience with it will make it somewhat difficult to displace PHP from its current position in the industry, no matter how much programmers like to gripe about it.

Two truths about identity

In announcing that he’s moving from working on Android to working on identity at Google, Tim Bray mentions two things about identity:

Usernames and passwords generally suck and obviously don’t scale to the Internet, so we need to do away with ’em soonest.

The new technology coming down the pipe, OAuth 2 and friends, is way too hard for developers; there need to be better tools and services if we’re going to make this whole Internet thing smoother and safer.

If he can make progress in attacking these issues in his new role at Google, the Web will be a much better place.

Economists explain how to write code

I enjoyed this coding manual prepared by University of Chicago economics professors Matthew Gentzkow and Jesse M. Shapiro for their research assistants. It’s a great short manual on how to code for clarity and performance. Considering the vast amount of really bad code that is produced in academia, it’s nice to see a focus on this sort of thing from professors. I especially enjoyed the parts where they give professional software developers too much credit. For example, here’s an assertion:

Real programmers write “unit tests” for every piece of code they write.

Would that that were true.

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑