Rafe – Page 33

Author: Rafe (page 33 of 989)

Stuff I need/want to spend time learning

June 23, 2012 / Rafe / 6 Comments

Just a short list of things I’d like to be learning right now:

tmux
More JavaScript
PostgreSQL (or their SQL variant, anyway)
Scala
statistics
R
Scalding
awk
Git (beyond trivial use cases)

Mike Loukides defines DevOps

Last week, Mike Loukides took a stab at defining DevOps over at O’Reilly. Until recently, I thought DevOps was just another buzzword, but I’ve changed my tune. The growing complexity of application infrastructure is the key factor in the transition of ops people into developers of another kind. Here’s Loukides:

Operations doesn’t go away, it becomes part of the development. And rather than envision some sort of uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away — it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as “DevOps.”

If you’re a Web developer or especially if you’re working on the operations side of the industry, understanding this trend and its implications is key to the future of your career. Even if this isn’t how things work at your current company, it probably will be at your next. Loukides’ article is a good place to start.

Why are Apple laptops becoming harder to take apart?

June 16, 2012 / Rafe / 63 Comments

You can probably imagine what the response of iFixit’s CEO was to the new MacBook Pro with Retina Display once he took it apart and found that it is probably the least user-serviceable laptop Apple has ever made. He hates it.

What I like about his piece is that he doesn’t place the blame on Apple. Instead, he puts it on consumers:

We have consistently voted for hardware that’s thinner rather than upgradeable. But we have to draw a line in the sand somewhere. Our purchasing decisions are telling Apple that we’re happy to buy computers and watch them die on schedule. When we choose a short-lived laptop over a more robust model that’s a quarter of an inch thicker, what does that say about our values?

I know a lot of people think that computers (and many other products) are becoming less maker-friendly because greedy companies want to get more money for parts and labor, or even better, shorten the upgrade cycle and sell more computers, or cars, or appliances, or whatever.

I doubt that is ever really the case. There are a lot of tradeoffs that go into product design. When it comes to laptops, there are capabilities (display resolution, processor speed, storage space, battery life, and so on), size and weight, cost, and upgradeability. Apple seems to have gotten the impression that upgradeability is the factor that people care about the least, and I suspect that they’re right.

My suspicion is that the number of people who upgrade any of the components of their laptops is very small — I’d be surprised if even 5% of customers did so. I would imagine that the number of people who repair laptops on their own is even smaller. What’s funny is that I’m one of those people. I unthinkingly set a magnet on a MacBook I used to have and destroyed the hard drive, and I was very pleased to be able to take it apart and replace that hard drive myself. That being said, I’d rather have one of the new MacBook Pros with Retina Display than that old MacBook any day of the week.

JC Penney and price shrouding

June 14, 2012 / Rafe / 2 Comments

I, like many people, thought that when Ron Johnson left his job running Apple’s retail operation to take over JC Penney, he’d turn things around completely. Not long after he took the job, he promised to completely remake the department store experience. One of the biggest experiments he tried was completely bucking the industry trend when it comes to pricing.

In January, the New York Time ran an article explaining Johnson’s plan, which involved simplifying the pricing structure and eliminating most large sales and promotions relating to those sales. This sounded like a great idea to me. The idea of going into a store and buying things without wondering whether I could get a better discount later by gaming the system seemed like a relief.

Based on the early results, I was completely wrong. JC Penney’s since they changed their pricing model have been incredibly bad. MSNBC’s Bob Sullivan explains why, in an article about price shrouding. In short, people feel like they get a better deal when they’re playing the game. The open question remains whether JC Penney is suffering poor results now but will rebound once consumers better understand what they’re doing. I wouldn’t count on it.

I think the lesson here for any product designer is that we have to really understand human behavior when we’re making decisions that depend on it. The Apple Store sells products that cannot be purchased more cheaply anywhere else. Furthermore, Apple’s profits are roughly the same whether you buy an iPod at an Apple Store or you buy that iPod at Best Buy. JC Penney does not retain either of those advantages.

Defining Big Data

June 11, 2012 / Rafe / 0 Comments

Here’s an interesting definition of Big Data, from Douglas Patterson:

One useful definition of big data — for those who, like us, don’t think it’s best to tie it to particular technologies — is that big data is data big enough to raise practical rather than merely theoretical concerns about the effectiveness of anonymization.

What’s the difference between a manager and a team leader?

June 9, 2012 / Rafe / 4 Comments

Today I was sort of idly thinking about the difference between a manager and a team leader. I suppose these terms mean different things in different organizations, but I think it makes sense to propose general definitions that clarify a somewhat hazy topic. We’ll assume that in both cases, the members of the team report to the manager or team leader, at least for the duration of the project that they’re working on. (If you work at a place where people have a manager and a team leader and the responsibilities are divided, all bets are off.)

Both are accountable for the overall performance of the team. If the team fails to meet its goals or is dysfunctional, that’s on the person who’s running the team, regardless of their title. I strongly prefer to think about these responsibilities in terms of accountability rather than authority for the reasons I talked about in my post about judgement and influence. I think that teams function most effectively when the members buy into the team goals individually because they see the value in them, rather than because somebody told them to do something.

So the difference is that a team leader should be thought of as the senior practitioner on the team whereas for a manager that may not be the case. If you’re the team leader of a team of developers, you should probably be the best developer on the team, and the other members of the team should respect your technical capabilities. If you’re the manager of a team of programmers, that’s not necessarily the case. A manager may be a fine programmer, but their core responsibility is management and coordination, not necessarily bringing an authoritative voice when it comes to making technical decisions.

The difference matters in terms of setting the expectations of the members of the team. It’s a dangerous thing when the members of a team think of the person running the team as a manager but they think of themselves as a team leader. Or if the team members have a manager they expect to be a team leader but who isn’t equipped to function in that role.

I’d be curious to know what other people think about these definitions. I haven’t heard of the two titles being defined this way before, but they match with my expectations based on my experience. I think that as an industry, it might pay off to formalize them.

Bitly demonstrates the wrong way to pivot

June 5, 2012 / Rafe / Comments Off

Last week Bitly announced that they’re morphing from a URL shortening service into a bookmarking service. I actually don’t think this is a bad idea.

Why do people start using URL shorteners? To share links that were unwieldy in the context in which they were to be used. I started using them in email because so many sites used URLs that were more than 80 characters long. It’s funny that with SEO and parameters used to track traffic sources, links are getting that long again. Anyway, that was the original use case.

One of the first thing Bitly did to add value beyond the basic shortened link was to offer analytics. When you shorten a link via Bitly, they collect basic analytical information about the people who click on it. So by using Bitly to shorten links you post to Twitter, you can get some idea of how many people are clicking on the links you share. This feature is remarkably useful, and is completely invisible if it’s not something you care about.

Bitly correctly assumed that people tend to shorten links that they care about, and that they may find value in having those shortened links saved as bookmarks so that users can come back later and view the archive. I think that was probably a good idea. I was a longtime user of Delicious and am a current user of Pinboard, and I have Pinboard automatically import any links that I post to Twitter. Most of those links are ones that I shortened using Bitly. In that sense, I’m pretty much the ideal use case for a Bitly bookmarking service. The main impediment would be that I have thousands of links stored in Pinboard already and I have no desire to move them.

The problem Bitly ran into is that they changed the basic link shortening workflow that people were used to. It used to be that if you shortened a link through the Bitly Web site or the Chrome extension, you’d immediately be presented with the shortened link. Unfortunately, Bitly has decided that promoting its new bookmarking service is more important, so now the first thing you’re asked to do is “Save this bitmark,” only after which can you see and copy the actual shortened link. Furthermore, Bitly gave you a nice box with the title of the page the link points to and the shortened link that you could easily post to Twitter with optional edits. That too is gone, replaced by a form that’s less useful.

Bitly would have really benefitted by enabling its users to wade into the new functionality rather than diving in. They should have maintained the old workflow and then presented a form that optionally allowed the user to add a description of the link, I think most users would have been much less frustrated with the changes. Bitly leapt out and tried to change a tool that people found pretty useful into a completely different tool. It’s not surprising that the existing user base revolted.

That said, Bitly needs to address this by tweaking the interface to satisfy existing users, not by throwing out the entire Bitmarks system. I think their idea that it’s a useful complementary service for them is correct.

The most wonderful sound in the world

June 4, 2012 / Rafe / 2 Comments

If you, like me, are an old school online enthusiast, click on this link just to listen to the embedded audio file. It’s the sound of a modem dialing up a remote computer and connecting. Like Madrigal, of all the nostalgic sounds I can remember, that one is the most magical. The accompanying story is quite interesting as well, but it’s worth clicking for the audio file alone.

The debate over share buttons on blogs

May 30, 2012 / Rafe / 1 Comment

In March, Jason Kottke launched a redesign that included something that I had long looked down on — sharing buttons. He explained:

I’ve always thought of kottke.org as a place where people come to find interesting things to read and look at, and design has always been crafted with that as the priority. A few months ago, I read an interview with Jonah Peretti about what BuzzFeed is up to and he said something that stuck with me: people don’t just come to BuzzFeed to look at things, they come to find stuff to share with their friends. As I thought about it, I realized that’s true of kottke.org as well…and I haven’t been doing a good enough job of making it easy for people to do.

After thinking about it, I agreed with that argument and added some sharing buttons to my post as well — only to services that I actually care about. Lots of people who I know use Facebook. I am a big fan of people sharing things on Twitter and Tumblr, and I find Hacker News to be useful at times as well, so I included those buttons.

Jason found that people are using those buttons. He has seen great results from mirroring his blog on Tumblr. I find that some people are using the buttons on my site as well.

Today, inspired by a post by Oliver Reichenstein provocatively entitled, Sweep the Sleaze, I learned that including those buttons made me look a bit desperate. Lots of smart people who I read agree with that assessment, and I more or less agreed with it myself until Jason Kottke changed my mind.

What Reichenstein’s post immediately made me think of was Nick Bradbury’s post from yesterday, Screw the Power Users. Here’s his advice:

But if you’re building a mainstream consumer product, then from day one you need to tell yourself, “screw the power users.”

That’s hard to do – after all, you’re a developer, so you’re one of the power users. You want to make people like yourself happy.

But I’d argue that’s one of the biggest problems that has plagued the software industry. We’ve all built stuff for ourselves, even though the vast majority of software users aren’t like us.

This is essentially the point of view that I came around to when I added the buttons. Am I a user of these share buttons? No. They’re a waste of space as far as I’m concerned. But other people do use them. They’re not slowing down the page load to any meaningful extent, and they’re pretty unobtrusive. I reserve the right to remove them the second they start to annoy me, but for now, I see including them as a worthwhile experiment.

In the meantime, writing a strident post entitled “Sweep the Sleaze” that takes dead aim at fish swimming around in a barrel is a much more obvious cry for attention than any number of sharing buttons on a blog post.

Twitter finally rejects their all-JavaScript approach

May 29, 2012 / Rafe / 2 Comments

When Twitter launched “new Twitter” in 2010, a lot of people decried it as a bad idea. The big change was sending every request to the site to one URL, which hosted a JavaScript application that requested the appropriate data and then converted it to HTML within the browser. Here’s Tim Bray explaining exactly why Twitter’s approach was wrongheaded.

About a year ago, Twitter platform engineer Dan Webb wrote an article rejecting hash-bang as well, which made it pretty clear that Twitter would be moving away from this architecture.

Today, Dan Webb has posted an official announcement that Twitter is dumping the “render everything in JavaScript” approach for performance reasons:

Looking at the components that make up this measurement, we discovered that the raw parsing and execution of JavaScript caused massive outliers in perceived rendering speed. In our fully client-side architecture, you don’t see anything until our JavaScript is downloaded and executed. The problem is further exacerbated if you do not have a high-specification machine or if you’re running an older browser. The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user’s machines rather than our own.

It feels good to see terrible ideas die, even when it takes awhile.

rc3.org

Strong opinions, weakly held