I get a link to a document on Google Docs. I click the link, and I’m greeted with this:

Seems reasonable.

This is likely because I have signed in with my personal account, which I must do to interact with YouTube. No problem, look at that “Sign in as a different user” link just begging to be clicked.

I click it, and one of two things happens: I get bounced to the contents page of my current account, with no prompt to log in as a different user whatsoever. This happens frequently. Alternately, I actually get prompted to sign in.

The Google Accounts login widget implicitly includes the domain portion of your email address.

Unfortunately, the regular login widget requires you to enter a full email address. And even if you have a Google Accounts account, and even if you were going to view a document in another account, you get the standard widget. This defeats tools like 1Password (which I use), as well as just being confusing. You get used to logging in on one way, then have to do it differently; because you’re never sure which one you’ll get, you have to pay attention. Friction, unhappiness, annoyance.

After successfully navigating this, what happens? I get sent back to the list of documents for the new account, rather than sent to the document I actually opened. Incredible.

After tracking down the original link and opening it again, you finally get to see the document, and now the real usability WTFs can begin. There’s a link in the document, which I would like to follow. When clicked, you get this:

I click it again. Do I get the page I wanted? No, I get a redirect through google.com.

Does Google have anyone working on UI/UX? This is absolutely horrible.

Unfortunately, the interface for this is a bit fiddly. I find myself taking one of two approaches:

1. Open a file as non-root, then hit C-x C-v and edit the filename to use /sudo:root@….
2. Hit C-x C-f, edit the directory to use /sudo:root@…, then open the file I want.

Since I didn’t like either of these, I wrote two functions to assist:

• find-file-as-root behaves as find-file, except the default shown is changed to be /sudo:root@…
• toggle-alternate-file-as-root is similar to toggle-read-only (C-x C-q), in that it will swap back and forth between the unprivileged version of a file and the as-root version.

I bind these to C-c C-x C-q and C-c x f, respectively.

There are two caveats. The first is that you must have tramp-default-proxies-alist configured for the sudo method to work on remote hosts. The second is that it is impossible to know for sure what the previous file name was after invoking toggle-alternate-file-as-root. Any buffer-local values are lost after replacing the buffer with the sudo version, and if I used a persistent structure outside of the buffer, it would require more complexity to prevent it from going stale. So instead, it just make a best effort to come up with something reasonable. Edge cases are going to fail, such as when you are editing a file as another non-root user. Patches are welcomed.

When I first got it (a week after launch), everyone wanted to know about it. Some of that magic has worn off, but it still turns heads. When I use it in public, everyone wants to know if I like it and how well it works. The number one question I get is, “how much a month does it cost?” and most people are surprised when I answer “nothing.” I have the WiFi model, and free WiFi is ubiquitous. The 3G model might be more useful for people who do a ton of traveling — and the addition of GPS is nice — but I’m not sure most people need it. It’s somewhat interesting that people assume that a mobile device has a monthly fee.

Since I got my it, I’ve stopped using my laptop for almost anything. For serious work, I have a desktop, and I use the iPad for almost everything else. The laptop only comes into play when I’m faced with the intersection of portability and work. For pure portability, it’s iPad all the way, and I use my iMac for straight work.

While the iPad is highly portable — much more so than a full laptop — I don’t take it everywhere like I do my iPhone. While the iPad provides a much better experience than the iPhone, it’s just not as essential. If I had to choose one device, it would be the iPhone. I find the myself taking the iPad places when I have a specific task for it in mind — if I want to write, or read a book. If I’m just going out, I usually leave it at home.

It shares a superficial resemblance with its smaller cousins, but very little beyond that; I use the iPhone and iPad very differently. The iPhone is geared more towards getting your attention for a short amount of time, while the iPad is better for focusing on one thing for an extended period of time. My iPhone is always asking for my attention: People call, text, or email, and I answer or reply. I turn all this stuff off on my iPad — If i’m reading a book or playing a game, the last thing I want is to be interrupted. It feels like something that should be used at its own pace.

When Steve Ballmer was asked about the App Store’s burgeoning catalog, he said that the majority were apps just to access web sites. I think that’s an exaggeration, but with a nugget of truth. With speed and real estate at a premium on the iPhone, native apps feel better, even when they have little to offer over a web app.

The iPad is the exact opposite. I use Safari for the majority of sites I visit, and the experience is fine. Because it’s both more capable and because I use it during times of leisure, I don’t feel the need for apps for most things. There are a few exceptions: I use Echofon because it doesn’t incessantly forget my credentials like Twitter does, and Reeder because Google Reader’s web interface is unusable on any platform.

iBooks

I find iBooks provides an excellent reading experience, and I use it often. I’ve read several books on it, and I enjoy the experience immensely. One thing I’d love to see is improved notes and annotations. Right now, notes are plain text, and I’ve found occasions where I’d like to annotate passages with photos or video, and this isn’t possible. Even URLs pasted into notes aren’t linked — you have to laboriously copy and paste them.

Even with the gorgeous display on my iPhone 4, real estate wins the day. Reading on the iPhone is cramped and I almost never use it for the extended periods necessary to complete a book. The sync feature is nice, though, and I will pull out the iPhone to read short passages if I’m waiting in line or such. I’d love to see a retina display on the iPad 2, but I’m not holding my breath. It would be amazing, but I think the display is fine as is.

My major gripe with iBooks is the store. DRM is odious for something you’re ostensibly paying money to own. You’re also locked in to Apple devices, since they’re the only ones capable of handling the DRM. Perhaps if the price were low enough that they felt disposable, it would be okay, but $10-$15 is more than I’m willing to pay. Copy-protected titles are also less functional than their free counterparts: copy and paste is disabled in any purchased book. The selection is not there yet, either. This is true to an extent of other ebook stores, but the situation with iBooks is definitely worse. While it can read DRM-free ePub books handily, I haven’t found a single store selling the sorts of titles I’m interested in without copy protection. I’ve discovered that Adobe’s Digital Editions DRM is easily strippable, so I’ve purchased a number of ebooks with it from online retailers, removed the DRM, and read the resulting DRM-free books on my iPad. It’s quite a run-around, though, and many of the books seem to have been corrupted (intentionally?), so every purchase requires much care and attention. It also needs a full and unrestricted computer; you cannot purchase and read these books directly on the iPad. The situation is extremely unsatisfying, and I hope it improves in the future.

The PDF support could also use some work. It’s usually good enough, but it doesn’t feel as natural as reading ePubs. The main problem is that PDF layouts are pixel-precise, and cannot be zoomed and reflowed. You can zoom in if the text is too small, but you must pan around to read it. Using an orientation different from the one the PDF was laid out in is an exercise in squinting frustration. PDFs are completely useless on the iPhone’s smaller screen.

Some people find the iPad too heavy to read on. Your mileage may vary, but it doesn’t bother me. It’s significantly heavier than a paperback, but not much heavier than a hardbound book, and much less bulky. Even when I am traveling for work, I usually bring the iPad along so I have something to read.

Work

I tried to see how viaible it was as a platform for working. For my job, at least, it’s not there, and I don’t know if it ever will be. Emacs runs natively on Macs, and it should be possible to port it to Cocoa Touch without much effort. But the nature of Emacs precludes it from ever getting approved in the app store, unless it was neutered to the point of near-uselessness. It depends on running lots of interpreted code and calling out to UNIX utilities which probably aren’t available.

I tried the next best thing, using the iPad as a SSH terminal with iSSH, a $5 universal SSH/Telnet/X11/VNC client. This isn’t as nice as native Emacs, because you need another system to log in to, but it could make an acceptable stopgap. First thing: the touchscreen keyboard is unusable for this kind of thing. The only reason a soft keyboard is viable at all is because of the autocorrection and completion features, neither of which work in iSSH. This isn’t a knock on the program, it’s just how things are.

With an external keyboard, the situation is improved, though still insufficient. You have the full screen for display, but the modifier keys on the keyboard don’t work. There is an open thread about this in the iSSH forums, but there doesn’t appear to be a fix forthcoming. You also cannot remap caps lock to be a control key. which is essential for efficient Emacsing. If these issues were addressed, the situation would be tenable — barely.

The other place it fails as a programmer work machine is in the multitasking model. I don’t have iOS 4.2 yet, but even when I do, it won’t be very useful. When I’m coding, I need the ability to quickly switch apps, but more importantly, I need to br able to SEE other apps. I very often have a primary Emacs window up with my code, and a web browser off to the side with reference material — API documentation and the like. I code, then glance at the docs, then go back to coding. There is nothing in iOS that can make this work, and I don’t know if there ever will be; it just requires a windowing model. I wholly admit that it’s not a case the average user cares about, but it certainly impacts my ability to consider the iPad a serious work machine.

On the other hand, my iPad has almost completely supplanted my iPhone and iMac as my preferred game machine. I’m obviously not a hardcore gamer, but hear me out. When Steve Jobs announced the original iPhone back in 2007, he touted the flexibility of the touchscreen to adapt to whatever sort of input the user needed, something physical input devices can’t do. This all falls down with games, particularly ports.

Games written with care for touch input can be fantastic: Spider: The Secret of Bryce Manor, Angry Birds, Zen Bound and so on. The problem is with action games that try to replicate d-pad style controls on a touchscreen. These are universally terrible, and it’s really too bad. There are two massive problems:

1. You lose screen real estate representing the controls.
2. There’s no way to know if you’re touching the right place.

The iPad is a lot better for #1, because the screen is so much bigger. The second problem, though, that’s s doozy. I played Assassin’s Creed 2 on my iPhone for a while, but the controls were just too rough. I’d end up dying because I hadn’t managed to stab the right bit of the screen, and it was quite frustrating. I played the same game on a NDS, and even with a smaller screen and worse graphics, it was much more enjoyable because the controls were massively better.

The best controls in a platform-style game I’ve found have been in Mirror’s Edge. They’re entirely gestural, feel natural, and aren’t frustrating. It’s clearly an exception to the general rule, and it has simpler controls which are more easily adapted to gestures.

It’s coming from inside the iPad!

Despite my criticisms, I really like my iPad, and I’m probably going to get the new one when it comes out. And despite my problems with it as a work machine, it’s quite capable for others’ needs. And the keyboard is really quite good: I wrote the bulk of this post with the touchscreen, then used a Bluetooth keyboard for final edits, cleanup, and posting.

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 pending branch. 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.