Talent

I wrote, Even if they still have the systems and the desire to roll back, they don’t have the talent to maintain Digg v3. I wasn’t saying that the current team is untalented. I know them to be an extremely bright group, and I have great respect for them. They are my friends and co-workers, and I meant them no disrespect.

I’ll put it another way: The institutional knowledge needed to maintain and extend Digg v3 no longer exists. The people who knew how Digg v3 works – and more importantly why it works that way – are gone. The people who still work there haven’t worked with the v3 code in any significant way in many months. It’s not that they couldn’t do it, but it would take some time to get up to speed with the v3 code.

Every indication from Digg has been that they will continue iterating on v4, and I think that’s the right thing to do. But I also think that going back is simply not an option, for the reasons I outlined.

Failure

I also said, rolling back to v3 would be an admission that v4 is a failure, which some might see as me calling v4 a failure. I don’t think that’s the case; it’s too early to say that it’s a failure or a success. Certainly, some people are upset, and this should surprise no one. Everyone at Digg knew that any change would make some number of users angry.

Digg v4 is not a redesign, not a reskin, it is a 100% rewrite. It’s completely new design, code, architecture, and infrastructure. It has almost no relationship to the v3 system whatsoever.

When we were figuring out how to launch v4, we settled on an extended side-by-side beta alongside v3, with a cutover when it was deemed good enough.

There were a few options on the table for managing the transition:

1. Keep the data completely separate during the beta period.
2. Have a one-way migration, where actions on v3 would show up on v4.
3. Have a two-way migration, where actions on either site would show up on the other.

We abandoned #1 because it would make the beta site less useful, and we’d still have to migrate the data eventually. We also wanted to be able to test v4 with the same data as we had on v3 to shake out bugs and get a feeling for the differences.

Option #3 was axed due to complexity. We didn’t even know what v4 would be like, and there might not be equivalent actions; and we didn’t have time to solve the problem of suppressing looping actions. That left #2 as the only viable option, and that’s the one we went with.

Now, assuming they deployed new servers for v4 and left the ones with v3 systems alone, it might be possible to relaunch Digg v3. It’s extremely unlikely it will ever happen, because it wouldn’t have any of the data accumulated since v4 launched. Getting all the data back into v3 would be a significant undertaking, and they’re still trying to get v4 under control. Not to mention the huge political implications: Rolling back to v3 would be an admission that v4 is a failure, and I just don’t see that happening.

I forgot to add: Even if they still have the systems and the desire to roll back, they don’t have the talent to maintain Digg v3. Nearly everyone who built and worked on the legacy Digg codebase has left the company. When I started at Digg, the engineering team was: Joe Stump, Matt Erkkila, Eli White, Steve Williams, Steve French, Kurt Wilms, Nancy White, Bill Shupp, and Micah Snyder. Operations had Ron Gorodetzky, Scott Baker, and Tim Ellis. Except for Matt, everyone else has moved on. There were others, but those people were the core team that made the legacy code work, and they’re gone now.

Edited again to add: I wasn’t saying that the current team is untalented. I know them to be an extremely bright group, and I have great respect for them.

Disclaimer: I worked for Digg from 2008-2010, and wrote a lot of the early code that would become Digg v4. I left Digg in May. My opinions are purely my own, and I have no inside knowledge of what has happened since I left or what will be happen in the future.

The situation has improved lately, with Andrew Bayer making significant improvements. With the features he’s added, reasonable and non-hacky workflows are no possible.

After some experimentation, this is what we’ve settled on at SimpleGeo:

1. Developers work on whatever branches they choose.
2. The work is reviewed and merged to the pending branch when it passes.
3. Hudson polls the pendingbranch. Changes are merged to master (in the repo on Hudson), and the build is performed.
4. If the build was successful, the result is pushed to the master branch of the repo on GitHub.

This works extremely well with GitHub’s Organizations and forking mechanism. Everyone at SimpleGeo has read-only access to all our repos. Each repo is owned by a particular team, and all team members have read-write access. Because of how Organizations work, any member can fork a private repo, and it will stay private — they don’t even need to be on a paid account. If someone wants to contribute to another team’s code, they just fork it, commit to their fork, and send a pull request to the owners. From there, the changes get reviewed and integrated into the pending branch, which triggers Hudson.

Most window managers have some facility to arrange the visible windows. With Emacs, you cna programmatically manipulate a frame’s size and position from Lisp.

There are a few ways I like to arrange my Emacs frames. I generally use one or two – more are harder to manage – and dedicate them to specific purposes. One always has code buffers in it, and the other can have compilation buffers, IRC, w3m, unit test output, or any other variety of programming-related tools.

When I work with a single frame, I like it to be centered on my screen. When I have two, I like them to be next to each other, in the center. Since it’s hard to align by hand, I wrote some code do to it for me.

(defun screen-usable-height (&optional display)
  "Return the usable height of the display.

Some window-systems have portions of the screen which Emacs
cannot address. This function should return the height of the
screen, minus anything which is not usable."
  (- (display-pixel-height display)
     (cond ((eq window-system 'ns) 22)
           (t 0))))

(defun screen-usable-width (&optional display)
  "Return the usable width of the display.

This works like `screen-usable-height', but for the width of the display."
  (display-pixel-width display))

(defun frame-sort-ltr (frames)
  "Sort frames by their visual order, left to right.

This method takes a list of frames, and returns that list, sorted
by the visual display order. This is determined by comparing the
left position of the frames; the leftmost frames are returned
first."
  (sort frames (lambda (framea frameb)
                 (< (frame-parameter framea 'left)
                    (frame-parameter frameb 'left)))))

(defun frame-box-get-center (w h cw ch)
  "Center a box inside another box.

Returns a list of `(TOP LEFT)' representing the centered position
of the box `(w h)' inside the box `(cw ch)'."
  (list (/ (- cw w) 2) (/ (- ch h) 2)))

(defun frame-get-center (frame)
  "Return the center position of FRAME on its display."
  (frame-box-get-center (frame-pixel-width frame) (frame-pixel-height frame)
                        (screen-usable-width) (screen-usable-height)))

(defun frame-center (&optional frame)
  "Center a frame on the screen."
  (interactive)
  (apply 'set-frame-position
         `(,(or frame (selected-frame)) ,@(frame-get-center frame))))

(defun frame-tile-horizonal ()
  "Tile visible frames horizontally.

This function tiles visible frames, distributing them evenly
across the display, and centering them vertically.

It doesn't know about multi-head displays, and will probably fail
dramatically if used in such an environment."
  (interactive)
  (let ((pos)
        (offset 0)
        (vwidth (/ (screen-usable-width) (length (visible-frame-list)))))
    (dolist (frame (frame-sort-ltr (visible-frame-list)))
      (setq pos (frame-box-get-center (frame-pixel-width frame)
                                      (frame-pixel-height frame)
                                      vwidth (screen-usable-height)))
      (set-frame-position frame (+ offset (car pos)) (cadr pos))
      (incf offset vwidth))))

(defun frame-tile-center-horizonal ()
  "Tile visible frames horizontally, center-weighted.

Rather than tiling frames evenly across the available width of
the display, this function tiles them into the center of the
display, adding a 2% margin in between frames.

It doesn't know about multi-head displays, and will probably fail
dramatically if used in such an environment."
  (interactive)
  (let* ((framewidth (apply '+ (mapcar 'frame-pixel-width (visible-frame-list))))
         (margin (/ (screen-usable-width) 50)) ;; = (/ s-u-w *.02) = 2%
         (totalwidth (+ framewidth (* margin
                                      (- (length (visible-frame-list)) 1))))
         (offset (car (frame-box-get-center totalwidth 0 (screen-usable-width)
                                            (screen-usable-height)))))

    (dolist (frame (frame-sort-ltr (visible-frame-list)))
      (set-frame-position frame offset (cadr (frame-get-center frame)))
      (incf offset (+ margin (frame-pixel-width frame))))))

(defun frame-restore-defaults (frame)
  (modify-frame-parameters frame default-frame-alist))

(defun frame-default ()
  (interactive)
  (mapcar 'frame-restore-defaults (frame-list))
  (if (> (length (frame-list)) 1)
      (frame-tile-center-horizonal)
    (frame-center)))

(provide 'ime-frame)

You can also call M-x frame-tile-center-horizonal or M-x frame-center by hand, if you like.

Ordinarily, you’d use *scratch*, but it’s useful to have your scratch buffer use mode for the language you want to write code in, and *scratch* doesn’t fulfill this unless you’re hacking on emacs-lisp.

To this end, I created scratch-el, a bit of code for doing just this.

When you invoke it with M-x scratch, it gives you a scratch buffer with the same mode as your current buffer. So if you’re editing Python code, you get a *python* buffer which uses python-mode. If you’re in a shell, you get a shell-script-mode buffer, and so on.

If you invoke it with a prefix argument, as C-u M-x scratch, it will prompt you for the mode to use, which can be helpful if you want to noodle on a SQL query while editing your app code. There is tab completion support for all known major modes.

If you want to save the resulting work, it’s just a C-x C-w away.

1. Own a Mac. If you do not currently own a Mac, go purchase one. I’ll wait.
2. Open the PDF in Preview.
3. Enter the password when prompted. (Which, inexplicably, is your email address.)
4. File→Save As
5. YOU_SUCK_APRESS.pdf
6. Rejoice in the knowledge that you can read your book however you please, despite the fact that it would have been easier to steal than purchase. Also, if you didn’t previously own a Mac, they’re pretty great, too.

Piece of Cake

The first component we’re going to work with is smerge. SMerge is invaluable; it’s a minor mode which allows you to quickly navigate between conflicts and choose which you’d like to keep. Normally, you must invoke it explicitly with M-x smerge-mode, but there’s an easier way.

(defun sm-try-smerge ()
  (save-excursion
    (goto-char (point-min))
    (when (re-search-forward "^<<<<<<< " nil t)
      (smerge-mode 1))))

(add-hook 'find-file-hook 'sm-try-smerge t)

Throw this in your .emacs, and smerge-mode will be enabled for files which contain conflict markers. If you’re a Git user (and you should be), the markers will have the branch names they came from tacked on the end. The minor mode will disable itself when there are no more conflicts left in the buffer.

All SMerge’s bindings start with a shared prefix, which is C-c ^ by default. This is somewhat cumbersome, but you can change it in customize (M-x customize-variable RET smerge-command-prefix RET). The bindings you’ll want to be familiar with are:

• C-c ^ n – Move to the next conflict.
• C-c ^ p – Move to the previous conflict.
• C-c ^ RET – Keep the version of the code point resides in.
• C-c ^ m – Keep my version of the code. This is the version that was in the branch you merged to.
• C-c ^ o – Keep the other version of the code. This is the version that was in the branch you merged from.
• C-c ^ a – Keep all versions of the code. You’ll probably need to edit it to completely resolve the conflict.

Another Slice

Let’s say that you have a file where you want to resolve each conflict the same way. You either want to keep the changes from the branch you merged, or the changes you've made in your branch. SMerge helps a lot with this, but there’s not reason to kill your fingers when you have KMacro. Let’s assume that you want changes in the branch you merged to take precedence.

1. C-x ( – Start recording a keyboard macro.
2. C-x ^ n – Move to the next conflict.
3. C-x ^ o – Resolve the conflict by choosing the other version.
4. C-x ) – Stop recording the macro.

Now, you can apply this macro as many times as you like with:

1. M-x kmacro-call-macro RET – Run the macro.
2. RET – Run the macro again; repeat until all conflicts are resolved.

You can argue that this doesn’t affect that many people, that most people will pay less and be fine, but I think the more interesting angle is how this reveals how AT&T just does not understand user experience the way Apple does. With unlimited data, you can whip out your phone wherever you are and use it. You never have to worry about your data usage, ever. Because you don’t have that barrier, you use the phone more. Because you use the phone more, you’re going to buy more apps and tell your friends, and they’ll buy phones and apps. It creates an ecosystem of consumption where everyone wins.

But now? Now you’ll be tempted to go look at your usage before streaming that movie. Now there will be a psychological barrier, however small, that makes you think twice about using your phone. More friction in the user experience. What Apple understands is that this friction, no matter how small, is an impediment to using the device, and they seek to eliminate as much of it as possible. AT&T either doesn’t understand or doesn’t care.

I have a rule of thumb, which is: Any deal, no matter how good it may seem to you, is usually more beneficial to the offerer. For example, how many times have you been offered 15% off your purchase if you sign up for a store credit card? I guarantee that they make the offer because they know that they will more than make up that one-time 15% on recurring fees, interest, and profit from purchases made with the card.

There’s just no way AT&T would do this unless they made money by doing it. Since they’re cutting the cost of the plan, you know they’re going to make that up somewhere. There are 6.4 million active iPhone users in the US, which adds up to $32m in lost revenue at $5 less per user.

Where do you think they’re going to make that up? Some of it is going to be in overages, though AT&T is more reasonable than some. But I’d wager that a big part of it comes from the recently announced ETF hike, which nearly doubled for iPhone users.

The only bright side to all this is that it seems like they’re telegraphing and end to iPhone exclusivity. They’re lowering the cost of staying slightly and significantly taxing the cost to exit, which suggests knowledge of a user exodus and an attempt to prevent it.

They should be back soon, hosted on Amazon S3 like the official 23.1 release.

Even if the iPad/iPhone ecosystem is less open in the comes-with-schematics sense, it’s far more accessible. For less than $2,000, you have access to the same tools and marketplace as anyone else.

For every get-off-my-lawn iPad curmudgeon, I bet there’s a half dozen kids who see slick apps and decide to go build their own.