Archive for July 21, 2015

Tuesday, July 21, 2015

Differential Synchronization

Neil Fraser (via Mike Ash):

Keeping two or more copies of the same document synchronized with each other in real-time is a complex challenge. This paper describes the differential synchronization algorithm. Differential synchronization offers scalability, fault-tolerance, and responsive collaborative editing across an unreliable network.

[…]

Differential synchronization is a symmetrical algorithm employing an unending cycle of background difference (diff) and patch operations. There is no requirement that "the chickens stop moving so we can count them" which plagues server-side three-way merges.

[…]

Despite the inherent complexity, this synchronization system works extremely well. It is robust, self-healing and (with the proper diff and patch algorithms) impressively accommodating of users who are working on the same text.

Dictation Buffer Updates

Nicholas Riley:

It’s been a little over a year since I started using Dragon Medical in Windows as a dictation buffer for my Mac. Please see my previous few posts on the subject for some background.

Since then, I’ve eliminated pain points and added features which have made the dictation experience smoother and less infuriating. Once again, while this does not represent a turnkey system, in keeping with the DIY nature of such projects, hopefully it may help others out who want to do something similar. The code remains up to date on GitHub and I plan on maintaining it for my own use until something better comes along.

xonsh Shell

xonsh (via @UnixToolTip):

xonsh is a Python-ish, BASHwards-compatible shell language and command prompt. The language is a superset of Python 3.4 with additional shell primitives that you are used to from BASH and IPython. xonsh is meant for the daily use of experts and novices alike.

Embrace Cross-posting

Manton Reece (congrats):

When App.net was first taking off, many microbloggers struggled with how to decide where to post their short-form writing. Should they post some topics to Twitter and others to App.net? Should they cross-post everything to both services? At the time, there was an informal consensus that cross-posting was a cheat. It couldn’t take advantage of each platform’s strengths, and followers might often see the same post twice.

I now believe that cross-posting is a good thing.

I’m now posting blog links to both Twitter and App.net, and each blog post now links to its day on my Twitter timeline. I’m not sure about cross-posting conversations, though. I don’t like reading the same posts twice.

My Two Years as an Anthropologist on the Photoshop Team

Charles Pearson (via Hacker News):

Almost two years ago, the Photoshop team pivoted to focus its energies and resources on design features and workflows. To be successful, the team needed to understand trends in design and tools, as well as develop connections and empathy to design and designers. Worth noting, the pivot happened not long after Adobe moved to a subscription service and away from big box releases every 1–2 years. The subscription model provided an opportunity for development to be more iterative, but so much had to be re-thought, including research and customer feedback loops. This was the task then: build deeper knowledge and empathy around UI design, as well as develop feedback loops suited to new development cycles. As an anthropologist and ethnographer (the first ever at Adobe!), I was hired as a consultant to help address those gaps.

[…]

While Photoshop had fantastic feedback loops and relationships with its photography and imaging customers, there was no real conversation happening with designers. The connections were weak.

[…]

We heard things like: “The limitations of Photoshop aren’t with visual design. It’s with capturing the experience — that’s where the barriers are.” Meaning, it was difficult to work quickly and efficiently on a design meant for multiple devices and/or multiple screens. It wasn’t easy to recycle and repurpose elements, to create a responsive design system.

[…]

The Photoshop team is organized by “molecules” — small teams of design, engineering, and management that work on a particular feature. So for example, one molecule, called Cyan (real name), developed artboards. Via a private group in Slack, which turns out to be easiest way to keep conversations focused and tight, we matched up around 20 designers with members of the Cyan team.