Rolandt

One of the common challenges involving a switch from macOS to an iPad is the lack of desktop-like clipboard managers on iOS.

By nature of the platform¹ and technical restrictions imposed by Apple, apps like Pastebot or Alfred wouldn't be able to adapt their Mac capabilities to the iPad. Third-party iOS apps can't constantly monitor changes to the system clipboard in the background; similarly, it isn't possible for an iPad app to register as the handler of a keyboard shortcut at a system-wide level. An app would have to at least be currently in use via Split View to listen for clipboard changes, but, even in that case, it would have to be active to receive external keyboard commands.

With these limitations, it's no surprise that clipboard managers aren't a flourishing category on the iPad App Store. However, once we accept the intrinsic differences between the Mac and iPad and if we look at the problem from a different perspective, there's plenty we can do – either with apps or automation – to go beyond Apple's modest clipboard offerings on iOS.

After years of testing iPad clipboard managers and automation/scripting strategies, this is what I've come up with.

Get More iOS Productivity Tips and Workflows

With a Club MacStories subscription, you’ll gain access to weekly iPad workflows, iOS app recommendations, and other exclusive extras.

Starting at $5/month, Club MacStories includes MacStories Weekly – a newsletter delivered every Friday with a focus on iOS productivity and showcasing new and interesting iOS apps. One of MacStories Weekly’s regular sections is the Workflow Corner – a weekly assortment of iPad workflows, iOS automation tips, and tutorials curated by Federico and the MacStories team.

As a new member, you’ll also receive complete access to our back catalogue of over 80 newsletter starting from September 2015.

You can find out more about Club MacStories here, or subscribe directly below.

Clipboard Manager: Copied

If you're looking for a standalone clipboard manager to hold bits of text (and images) to sync them across devices with iCloud (something most Mac clipboard apps won't do), I recommend Copied.

I covered Kevin Chang's app on multiple occasions before, and it is an essential addition to my writing workflow whenever I'm dealing with a longform document that requires shuffling portions of text between apps. I could get work done without Copied, but I'd be noticeably slower.

Copied is, in many ways, an iOS-first clipboard manager. It's built for a platform where optimal efficiency doesn't lie in background monitoring and invisible execution, but in native integrations with apps and the OS.

There are five ways you can save text and images into Copied from any iPad app:

• A headless (no UI) action extension that saves content directly into Copied;
• A second action extension that brings up a clipper UI to confirm and transform content before clipping it;
• A widget to save the current clipboard contents;
• A custom keyboard to save text from any app that has a text field.
• When Copied is in Split View, a 'Save Universal Clipboard' setting saves anything that is copied from another app.

The multiple options to save content in Copied epitomize the path to success for most iPad productivity apps. Rather than pursuing inconvertible macOS features, a new kind of power can be unlocked by deeply integrating with iOS. Copied does this extremely well.

Copied's widget is one of my favorite aspects of the app. In compact mode, it lets you preview what's currently in your clipboard or save the clipboard with the tap of a button. Expand it, and you'll get access to Copied's lists – effectively, folders where you can store clippings for better organization.

Copied's widget in compact and expanded mode.

The ability to set up permanent lists to archive text and images makes Copied more than a volatile clipboard manager – especially if you set the app to keep 500 or 1000 clippings and sync them with iCloud. I've saved dozens of snippets in dedicated Copied lists, which I tend to re-copy from the widget to paste them elsewhere (usually Airmail, Tweetbot, or Slack).

The custom keyboard, despite Apple's lack of attention for this third-party feature, is equally impressive when you need to bring multiple pieces of content into an app.

Normally, desktop clipboard managers would appear as floating popups with a list of previously copied items on top of the app you're using, or they would require a sequence of keyboard shortcuts to navigate their item history. With its custom keyboard, Copied becomes part of the app you're using: a grid of clippings can appear alongside a document you're writing or iMessage you're composing, enabling you to insert several bits of text or images in a row just by tapping on thumbnails in the bottom half of the screen. I haven't been an assiduous user of custom keyboards, but I want to turn Copied's keyboard into a habit.

The Copied I've described so far is a versatile clipboard manager that turns the platform disadvantage of iOS into a series of integrations to simplify the saving of text and images. There is, however, a deeper layer to Copied's functionality that warrants the app's "desktop-class" status: text transformation through merge scripts and templates.

Copied comes with a template system that lets you programmatically alter text through built-in plain text variables as well as JavaScript. With templates, you can create text formatters that allow you to dynamically modify a clipping before sharing or pasting it into another app; with merge scripts, you can restructure and join multiple clippings using the app's Merge feature.

Here's an example: when saving a URL from Safari, the Copied extension knows that the URL is associated with a webpage, which has a title. With templates, you can create a text formatter that, upon sharing the URL clipping, creates a prettier version of it with the title enclosed in quotes, followed by a colon, a space, and the original URL.

A custom text formatter applied to a URL upon sharing it.

How about turning URLs into Markdown links or, even better, their HTML counterparts? It's all very easy with Copied's text formatters.

Copied (in dark mode) with a custom HTML link formatter.

It gets better when you want to manipulate text. Whether you need to turn a webpage selection into a shareable quote, URL-encode a string of text, remove whitespace, or change case, Copied lets you do so in a second with built-in JavaScript formatters. And that's not all: you can add your own JavaScript actions based on Copied's custom clipping object and run them from inside the app, the Clipper extension, or before pasting into a text field with the custom keyboard.

A script in Copied, made with JavaScript.

You can reformat copied text from the custom keyboard before inserting it into a document.

The same JavaScript system is used for custom merge scripts. When merging multiple clippings, you can tap 'Apply Template' to pick a script that will join text lines depending on what's defined in the template. No code is shown while merging and you can preview results before running the script.

By default, Copied comes with built-in scripts to join lines of text as a numbered list or with a line separator. I created a custom merge script to convert multiple URLs into a Markdown list where each link uses the title of the webpage. With this script, I was able to turn dozens of URLs captured with the Safari extension into a Markdown list (which you can see here) in seconds.

Copied is more than a clipboard manager. Copied uses the iOS clipboard as a starting point for new clippings and to store content you may want to paste elsewhere, but its biggest asset is the integration with native iOS technologies. Thanks to widgets, extensions, custom keyboards, Split View, Safari View Controller, JavaScript, and its several other features², Copied shows that powerful clipboard management on the iPad doesn't have to be modeled after macOS.

A Plain Text Clipboard Manager, Created with Workflow and iCloud Drive

If you don't want to use Copied, Workflow lets you interact with the iOS clipboard through built-in actions, too. To demonstrate the depth of Workflow applied to clipboard management, I created my own mini clipboard manager using Workflow, iCloud Drive, and widgets.

With my Workflow-based clipboard manager, you can prepend anything you've copied or any input from the action extension to a text file named Clipboard.txt synced with iCloud Drive. There's a check in the workflow to make sure that the Clipboard.txt file exists under iCloud Drive/Workflow; if it doesn't, it's created by Workflow on your behalf.³

Saving the clipboard from a Workflow widget.

Previously saved items.

The workflow lets you specify the number of text lines the file should keep as history; if you choose 50, as soon as you're about to save line 51, one line from the bottom of the file will be deleted. Thanks to iCloud Drive's background sync privileges, Clipboard.txt is synced automatically and propagates across devices almost instantly.⁴

The iCloud Drive file behind clipboard automation Vs. its representation in the workflow.

Using the workflow couldn't be easier: copy something, open the widget, and tap it; text will be instantly saved to Clipboard.txt . Alternatively, if you want to capture something from the extension, invoke the workflow and run it. A text line will always be prepended at the top of the text file.

Saving a webpage to <code>Clipboard.txt</code> from Safari.

Thanks to the Content Graph engine, this workflow supports the following input types, both from the clipboard and the action extension:

• Plain text
• Rich text
• URLs
• Safari webpages
• Apple Music songs
• iTunes Store products
• App Store apps
• Apple Maps locations

When you want to fetch text you've previously saved, there's a separate workflow that displays lines of text from Clipboard.txt in a widget. You can tap an item to copy it again. Everything is beautifully integrated with iOS and it works like magic. The workflow's complexity is entirely abstracted from the experience; I built these workflows to seamlessly save anything you want to a text file in less than 5 seconds.⁵

Items previously saved to the iCloud Drive text file can be accessed from anywhere with the Workflow widget.

Despite my love for Copied, I've been using these clipboard workflows to quickly store anything I come across in iCloud Drive, and they've been working well on both my iPhone and iPad. You can download them here:

• Clip to iCloud Drive
• Get iCloud Drive Clipboard

Other Useful Clipboard Tricks

Finally, I have some additional suggestions to avoid clipboard management headaches on the iPad.

Use 'Paste and Go' in Safari. If you copy some text that contains a link, you can tap and hold Safari's address bar to quickly open the URL from the clipboard.

Tap and hold to open a copied URL directly.

Even better, if what you copied is a mix of text and a URL (the kind of text that my workflow generates, for instance), Safari's Paste and Go will still work as it can extract the link from the clipboard on its own. I use this dozens of times every day.

Set up a widget launcher to share the clipboard. Using either Workflow or Launch Center Pro, you can set up one-tap widgets that send the contents of the clipboard to iOS extensions using the share sheet. Here's an example.

Copy without Universal Clipboard. Want to copy something without sharing it across devices through Universal Clipboard?⁶ You can enable the 'Local Only' option of Workflow's 'Copy to Clipboard' action to save content exclusively into the clipboard of your current device without sharing it. You can also set an expiration date if you want to make the clipboard available to other devices until a specific time.

Turn the clipboard's contents into files. Sometimes, you just want to create a file from what you've copied. As I mentioned last week, DEVONthink's document creation menu can recognize text, URLs, and images you've already copied and save them into its database.

There's a lot you can do with the iPad's clipboard if you accept that iOS clipboard management can't be like macOS – at least for now. With a mix of Copied, automation with Workflow, Split View, and widget launchers, it's already possible to take the system clipboard to the next level. I hope to see meaningful clipboard improvements in iOS 11.

iPad Diaries is a regular series about using the iPad as a primary computer. You can find more installments here and subscribe to the dedicated RSS feed.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it’s also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it’s made in Italy.

Design Code Build and Girl Scouts San Diego are developing a curriculum to teach girls programming and design by building a game called Marshmallow Run. It’s an ambitious program to bring Marshmallow Run to life through Scratch, the web, iOS, and Android as a way to reach girls of all age levels and provide opportunities that will appeal to a wide variety of interests. To make the program a reality, Design Code Build and Girl Scouts San Diego launched a Kickstarter campaign to cover the cost of computers, meeting space, developer accounts, and other overhead.

What’s unique about the Marshmallow Run campaign is its breadth. The project isn’t constrained by the programming platform chosen or other structural decisions that might limit its appeal. Design Code Build has developed the characters for Marshmallow Run, but the rest is up to the girls who participate in the program. The participants will have the opportunity to learn to program physics into a game, design levels, set timers, detect collisions, along with everything else that programming a platformer game entails. Girls will also learn graphic design, storyboarding, audio design, and much more. The result is a curriculum designed to foster imagination and creativity in a fun way that teaches new skills.

The project’s campaign has just 3 days left to reach its goal of $25,000. As of publication, pledges are just over 50% of that goal. If Marshmallow Run is funded, backers will receive a variety of rewards depending on their pledge levels including stickers and t-shirts, but the reward that’s most interesting is a programming starter pack for backers who pledge just $25. The starter pack includes character sprites and other game elements for building Marshmallow Run in Scratch. At higher pledge levels backers receive beta access to the web and mobile versions of the game. The starter pack and access to the betas are a terrific way that Design Code Build and Girl Scouts San Diego are sharing what they hope to create beyond their local community.

I have three boys and have experienced the frustration of trying to find opportunities for them when they wanted to learn to program. There just aren’t enough good programs available for kids in general, and even fewer for girls. Marshmallow Run is a chance to start fixing that, foster the next generation of programmers and designers, and make a difference in addressing the gender imbalance in tech fields.

If you want to make a pledge, you can do so on the Marshmallow Run Kickstarter page.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it’s also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it’s made in Italy.

Personal Projects are crucial in showing potential buyers how you think creatively on your own. I am drawn to personal projects that have an interesting vision or show something I have never seen before. In this revised column, I’ll include a link to each personal project with the artist statement so you can see more of the project. Please note: projects are found and submissions are not accepted.

Today’s featured artist: Vincent Dixon

To see more: http://vincentdixon.com/wanderings/category/The+Train+Ride/

In 2011/12 I took a year off to travel around South East Asia and South America with my wife and four children. 

We had been on the road three months when we crossed the border from Nepal to India. I was nervous, I didn’t really know what to expect but had heard from other travelers that India was pretty chaotic. Just crossing the border conformed that. The station wasn’t much better, finding which platform our train was using wasn’t easy. We had been warned that people will always give you an opinion whether they know the answer or not. The 10 pm train was delayed, first for an hour, then two, it finally came to the station four hours late having apparently switched platforms several times. We boarded to find a family asleep in our bunks, gently woken they moved and I took a wet wipe to the top bunk, one swipe and the imprint of my hand was black, Ainlay my wife distracted the kids as I cleaned all the beds, we put our sneakers  on top of the old electric fans as we saw everyone else do, used our backpacks as pillows and got a few hours sleep. When I woke up I took some photos.
http://www.briteproductions.net/vincent-dixon

—————

APE contributor Suzanne Sease currently works as a consultant for photographers and illustrators around the world. She has been involved in the photography and illustration industry since the mid 80s. After establishing the art buying department at The Martin Agency, then working for Kaplan-Thaler, Capital One, Best Buy and numerous smaller agencies and companies, she decided to be a consultant in 1999. She has a new Twitter feed with helpful marketing information because she believes that marketing should be driven by brand and not by specialty. Follow her at @SuzanneSease.

------------------------

Visit our sponsor Photo Folio, providing websites to professional photographers for over 9 years. Featuring the only customizable template in the world.

------------------------

The glorious view from our windows at Cornell Tech takes in 432 Park Avenue, the tallest residential building in the world. This tower is a monument to many things. Above all, for a student of Financial systems, it epitomizes ways to store wealth with breathtaking waste. (Fittingly, it was inspired by a wastepaper basket, shown to the right.) Buildings like it are sprouting up around NYC as investment vehicles for the ultra-wealthy, and their owners don’t actually live much in them. 432 Park and its ilk are essentially hollow vaults.

Something similar can be said for Bitcoin. As a concept and technological inspiration, Bitcoin is a marvelous thing. And unquestionably like 432 Park, it does see legitimate and valuable uses (and some shady ones). As a currency, though, Bitcoin serves in no small degree as a wasteful and ecologically damaging way for people to park their money.

There are a number of ways to substantiate this claim. One is in terms of its electricity consumption. Estimates vary, but it is likely that the Bitcoin network consumes roughly as much electricity as a nuclear reactor, about 1/3 of the entire electricity consumption of the entire country of Ireland. (See our back-of-the-envelope calculations in the blog notes.) To view this in another light, a recent IC3 paper estimated the cost-per-confirmed transaction at as much as $6.20 in capital costs and electricity. (Transaction rates have been rising, and today the figure is substantially lower, but still high.) That’s $6.20 in resources per transaction to move money between accounts in the same system.

Bitcoin proponents argue that this is simply the cost of decentralization. A credit-card network doesn’t provide the pseudonymity, freedom from government interference, portability, and other features of Bitcoin, so it isn’t comparable. This is true. But it isn’t a law of nature that a system like Bitcoin should be so resource-intensive. Researchers at IC3 believe that the many benefits of Bitcoin can be had without the waste. In a few papers released over the past month or so, we’ve outlined three different approaches to the development of greener alternatives:

1. PieceWork is a tweak to standard cryptocurrency PoWs that enables recycling of mining effort.
2. Resource-Efficient Mining (REM) repurposes innately useful workloads for mining effort. It relies on use of a trusted hardware technology called Intel SGX.
3. Snow White is the Proof-of-Stake system with rigorous security guarantees.

PieceWork: Recycling PoWs

If we can't reduce waste at the source, why not recycle? That's the premise of the first, and simplest idea, called PieceWork. Piecework involves a slight modification to the standard Proof-of-Work (PoW) construction, decomposing it into two layers. One layer produces small PoWs called puzzlets that play a critical role in the mining process and can also, as we shall show, serve useful non-mining purposes.

Consider a standard cryptocurrency, abstracting away into a single value X the details of what gets hashed into a PoW (transactions, the previous block, etc.). A miner’s task then is is simply to search for an input (“nonce”) n∈N for which

H(X, n) ≤ Z,

where Z is a threshold representing the difficulty of the PoW.

To decompose a PoW into two layers, we instead construct it as follows:

H(X, n) = F_out (X, F_in (X, n; r_in ), r_out ),

where r_in = H0(r) and r_out = H1(r) for distinct hash functions H0, H1 and a secret value r. (These two values are a technical requirement to prevent what are called block withholding attacks. See the blog notes.)

A valid solution is a value n such that

F_in (∙, n, ∙) < Z_in and F_out (∙, n, ∙) < Z_out.

To solve this puzzle or PoW, a miner must first find an n such that F_in (∙, n, ∙) < Z_in. This inner-puzzle is what we call a puzzlet. To solve the whole PoW, a miner must find a puzzlet solution. The puzzlet solution must additionally satisfy F_out (… n…) < Z_out, meaning that a miner must in general come up with many puzzlet solutions to solve the PoW as a whole. By setting Z_in + Z_out = Z, one obtains a PoW with the same difficulty as that in (1).

What’s the benefit of this two-layered structure? A puzzlet, i.e., the task of finding a solution n to F_in (∙, n ,∙) < Z_in, can be outsourced by a miner or mining pool operator to a worker, and put to any of several non-cryptocurrency goals. DoS prevention for TLS is one example. TLS requires computationally intensive crypto operations from a server to set up connections. Thus it’s a natural target for DoS attacks, prompting the idea of requiring clients to solve PoWs if a server comes under attack, an idea now floated in an IETF proposal. These PoWs used for DoS mitigation can themselves be puzzlets. The effect is that the server becomes a mining pool operator, and its clients become workers. And a DoS attacker effectively showers the victim HTTPS server with cryptocurrency. (Of course, a server can also dispense puzzlets and make money even when it’s not under attack…) Other examples of puzzlet uses are spam prevention (the original PoW goal proposed by Dwork and Naor), MicroMint, and Tor relay payments.

In summary, PieceWork requires only a small modification to standard cryptocurrency PoWs. It turns them into dual-use computational problems and recycle wasted mining effort. How much recycling it can feasibly accomplish is an open research question. PieceWork benefits from a number of previous, related ideas. Our short paper on it can be found here. PieceWork will be presented in April at BITCOIN 2017.

Resource-Efficient Mining (REM): Using Innately Useful Work as Mining Effort

A very different approach to minimizing waste is embraced in our second project, a system called REM. Rather than relying on hash-based PoWs, it makes use of an entirely different type of PoW, in which the W, i.e., the work, is useful. We call this concept Proof of Useful Work (PoUW).

Of course, traditional PoWs have several useful properties, prime among them the ease with which solutions can be verified. Most workloads don’t have this property. To enable verification of work on arbitrary useful workloads, REM relies on a new technology: Intel SGX.

Intel’s new SGX (Software Guard eXtensions) trusted execution environment technology. In a nutshell, SGX enables the execution of an application in a hardware-protected environment, called an enclave, that is isolated from the operating system and other applications. It thus protects the application against tampering by even the owner of the machine on which it’s running. SGX also enables generation of an attestation that proves to a remote party that a particular application was running in an enclave. SGX is already supported in many recent-model Intel CPUs.

As a good way to see how SGX can facilitate mining, it’s worth discussing an elegant mining scheme proposed by Intel called PoET (Proof of Elapsed Time). The idea behind PoET is simple. If miners use SGX, then they can be forced to use only a sanctioned piece of mining software that simulates PoWs. Standard PoWs have solution times that are exponentially distributed. A PoET client can thus sample a solution time from an exponential distribution, simply sit idle until this time elapses, and then wake up with a block in hand. The first client to awake gets to publish its block. An SGX attestation proves to others in the system that the client idled as it should have.

PoET has several nice features. Foremost among them is the fact that (at first glance) it’s virtually energy-waste-free. Clients idle instead of hashing. Block solution times can be tuned to mimic those of a standard mining regime, like Bitcoin or Ethereum mining. Thus PoET can effectively be plugged into such schemes. It is also relatively egalitarian in that it achieves precisely one vote per CPU. PoET, though, has two technical challenges. We call these the broken chips and stale chips problems.

First, the broken chips problem. SGX security is imperfect and, as with any trusted hardware, it’s to be expected that a well-resourced adversary can break it. Thus, it’s to be expected that some SGX CPUs will be broken. In the basic PoET scheme, a broken chip has devastating effect, as it enables a miner to simulate a zero mining times and win every consensus round, i.e., publish all blocks. Intel has proposed a statistical testing regime to detect breaks, but details aren’t published and formal foundations are needed for a good analysis.

REM faces the same challenge. In REM, we have developed a rigorous statistical testing regime with formal foundations and shown analytically and empirically that it is highly effective: It can strictly limit the gains of adversaries that have broken chips while minimizing incorrect rejection of blocks from honest miners.

The stale chips problem is more subtle. Our economic analysis shows that in many practical settings in PoET and related systems, it will be advantageous for a miner to buy old (“stale”) SGX CPUs and cobble them together into “farms” that mine cheaply. Such farms reinstate a fraction of the waste that PoET is trying to avoid to begin with. This is where REM’s Proof of Useful Work (PoUW) approach comes into play. In a nutshell, with PoUW, miners run whatever workloads they consider to be useful---protein-folding computations and ML classification algorithms are a couple of examples considered in our work. Miners can prove that they did work on these problems using SGX. The probability of a miner mining a block is proportional to the amount of work she does. Thus, REM turns otherwise useful work into mining effort. Making PoUW work is technically challenging. It requires that workloads be themselves compiled and instrumented using SGX to prove correctness, an innovation of independent interest introduced in REM.

The biggest objection lodged against SGX-based mining is the fact that it places Intel in charge, undermining the decentralization at the heart of permissionless ledgers. Of course, Intel is already a trust anchor. But we’d view this another way, and characterize REM and PoET as partially decentralized. You can read about REM here, in a paper under submission.

Snow White: Proof of Stake with Rigorous Security Guarantees

Our final approach to reducing cryptocurrency waste is one both proposed and studied by many projects in the cryptocurrency community since the inception of Bitcoin. This idea is called proof of stake, and revolves around the basic premise that rather than mining simulating a lottery where your chance of finding a block is proportional to computing power, mining simulates a lottery where your chance of finding a block is proportional to the number of coins (or “stake”) you have in the system.

A key roadblock to the adoption and deployment of proof of stake systems involves questions around the security guarantees that they provide. This continues to be an ongoing source of controversy and debate in the community, with sources like the Bitcoin Wiki claiming that “Proof of Stake alone is considered to an unworkable consensus mechanism” and efforts like Ethereum’s Casper project studying questions of how to design a maximally useful and relevant proof of stake protocol for the next generation of cryptocurrencies.

Despite its potential shortfalls, we believe proof of stake represents a critical new development and direction in both the blockchain and distributed consensus fields. With this in mind, we set out to apply previous work by Rafael Pass (an IC3 member) and others, in which a model for analyzing and proving consistency, chain growth, and restrictions on adversarial chain impact for proof of work blockchains was developed.

To more accurately model the nature of blockchain distributed consensus, and the implication of network delays, we propose a new model for consensus called the sleepy model. This model more accurately mimics the operation and naturally captures the design of permissionless blockchains. In the sleepy model, a user (node or miner) can leave or join the protocol at will. This is modeled by (non-crashed) users in the protocol being given the ability to “sleep”, or go offline and rejoin the network at some unspecified later date with unmodified original state. The key question then becomes how can we design a useful consensus protocol in the sleepy model, when at least half of all online nodes (or stake) is honestly following the protocol?

The guarantees of consistency and availability are rigorously defined in this new model, more accurately capturing the guarantees users expect from blockchain protocols. The analogues of proof-of-work style guarantees like chain growth (availability) and chain quality (integrity) are also discussed. We believe this new class of consensus protocols in the “sleepy” model represents one of the fundamental contributions of blockchains to the distributed consensus space. Neither the asynchronous, partially synchronous, or synchronous models, in either a permissioned or permissionless setting, prove sufficient to model or reason about these new consensus protocols or the probabilistic and often economic guarantees they provide.

To that end, we are working on two protocols proven in the Sleepy model: Sleepy and Snow White.

Sleepy is a simple protocol intended to achieve the guarantees of chain quality, chain growth, and consistency/agreement with 51% of online nodes being honest. This protocol is intended for deployment in a permissioned context, and assumes stake assigned or instantiated by some trusted source. This makes Sleepy ideal for bankchains or other permissioned deployments, in which the set of stakeholders is known a priori but the blockchain guarantees of robust, auditable distributed consensus remain desirable. Every second, every member of the committee is eligible to “mine” a new block in the system, which involves a standard block mining solution with a public source of entropy as the nonce. Standard difficulty adjustments retarget the block interval to a desired target, as in Bitcoin and Ethereum today. The challenges of choosing an appropriate, ungameable mining function and source of entropy are tackled in the work, and proof is given that no committee member can manipulate the protocol to their advantage.

Snow White, on the other hand, is an extension of Sleepy intended to provide the same rigorous blockchain-derived guarantees in a permissionless setting, such as in the deployment of a public cryptocurrency. Obviously, this is substantially more difficult: choosing appropriate committee members for the block lottery, as well as ensuring that no coalition of these committee members (of bounded size) can game the protocol for more than a negligible advantage, are highly nontrivial. The resulting protocol is actually quite simple: each step, a committee mines as in Sleepy, with a shared source of entropy h0. With sufficiently many bits of entropy in h0 and an appropriately selected committee weighted on stake, it is possible to prove the desired result of chain quality, growth, and consistency in the Sleepy model. Choosing both the committee and h0 such that no adversary or non-majority coalition of adversaries gain substantial advantage by deviating from the protocol is the key to the construction and concrete parameters of the protocol, which are discussed further in our full publication.

Sleepy and Snow White represent the first rigorously justified and proven blockchain consensus protocols in both the permissioned and permissionless proof of stake space. It is our belief that the rigorous proofs of security are valuable as both theoretical efforts and to guide protocol development and deployment. Both the proof and concrete parameterization of these protocols are highly non obvious, and while heuristic protocols designed elsewhere in the community (with only informal justification) may operate in a similar manner to Sleepy, there is no guarantee that subtle network-level, timing, committee / stake poisoning, and other attacks are not present in these protocols. In our work, we assume an optimal adversary with ability to delay network messages up to some arbitrary time, a very strong notion of attacker that makes our protocols the most rigorous conceived in the space thusfar.

You can read about the papers in prepublication manuscripts we have uploaded for release on ePrint: Snow White, Sleepy. Further conference or journal publications with implementation details of these systems, full proofs, simulation results, and experimental comparisons to existing cryptocurrencies are currently in development. We hope to share more exciting news about these new protocols soon.

[It is worth noting that our willingness to assume that the majority of online coins are honestly following the protocol is an assumption that `has been challenged <https://blog.ethereum.org/2016/12/06/history-casper-chapter-1/>`_ by the Ethereum foundation. We do not necessarily agree with these criticisms or model; we believe that the ε-Nash equilibrium achievable in *Snow White is sufficient for the design of a robust, decentralized coin. Nonetheless, we believe developing and proving protocols secure in this context is valuable: both as the most natural model for private blockchain deployments, and to illuminate common pitfalls in proof of stake protocol design that may lead to attacks in naive protocols. We look forward to a full specification of Ethereum’s Casper, and to comparing both its assumptions and attack surface with that of Snow White.

Nearly one year ago Google launched Gboard, a third-party keyboard for iOS that brought the power of Google search to iOS's keyboard. The company has continuously improved the keyboard over time, with updates including support for multiple languages and a 3D Touch-powered trackpad mode. Earlier this year the keyboard was integrated with Google's standard search app. Today the improvements continue with three separate highlights.

Dictation

The default iOS keyboard has long presented the option to dictate text rather than type it, and Gboard has gained that ability starting today. Users will notice a speaker icon that now appears on the right side of the space bar. Long pressing that speaker icon will engage dictation mode.

Doodles

Google's Doodles add a sense of whimsy to the company's search page, but until today searching through Gboard meant missing out on Doodles. Going forward, whenever a Doodle is available the "G" button on the left side of the keyboard will animate, indicating you can pull up the Doodle with a quick tap.

Languages and Emoji

In addition to support for many new languages – Croatian, Czech, Danish, Dutch, Finnish, Greek, Polish, Romanian, Swedish, Catalan, Hungarian, Malay, Russian, Latin American Spanish and Turkish – Gboard has also been updated to enable searching for and using the new emoji that Apple added to iOS 10.

Gboard can be downloaded from the App Store.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it’s also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it’s made in Italy.

Editor’s note: This is the fourth chapter of a book I’m working on called Demystifying Artificial Intelligence. I’ve also added a co-author, Divya Narayanan, a masters student here at Johns Hopkins! The goal of the book is to demystify what modern AI is and does for a general audience. So something to smooth the transition between AI fiction and highly mathematical descriptions of deep learning. We are developing the book over time - so if you buy the book on Leanpub know that there are only four chapters in there so far, but I’ll be adding more over the next few weeks and you get free updates. The cover of the book was inspired by this amazing tweet by Twitter user @notajf. Feedback is welcome and encouraged!

“A learning machine is any device whose actions are influenced by past experience.” - Nils John Nilsson

Machine learning describes exactly what you would think: a machine that learns. As we described in the previous chapter a machine “learns” just like humans from previous examples. With certain experiences that give them an understanding about a particular concept, machines can be trained to have similar experiences as well, or at least mimic them. With very routine tasks, our brains become attuned to characteristics that define different objects or activities.

Before we can dive into the algorithms - like neural networks - that are most commonly used for artificial intelligence, lets consider a real example to understand how machine learning works in practice.

The Big One

Earthquakes occur when the surface of the Earth experiences a shake due to displacement of the ground, and can readily occur along fault lines where there have already been massive displacements of rock or ground(Wikipedia 2017a). For people living in places like California where earthquakes occur relatively frequently, preparedness and safety are major concerns. One famous fault in southern California, called the San Andreas Fault, is expected to produce the next big earthquake in the foreseeable future, often referred to as the “Big One”. Naturally, some residents are concerned and may like to know more so they are better prepared.

The following data are pulled from fivethirtyeight, a political and sports blogging site, and describe how worried people are about the “Big One” (Hickey 2015). Here’s an example of the first few observations in this dataset:

Just by looking at this subset of the data, we can already get a feel for how many different ways it could be structured. Here, we see that there are 10 observations which represent 10 individuals. For each individual, we have information on 11 different aspects of earthquake preparedness and experience (only 3 of which are shown here). Data can be stored as text, logical responses (true/false), or numbers. Sometimes, and quite often at that, it may be missing; for example, observation 1013.

So what can we do with this data? For example, we could predict - or classify - whether or not someone was likely to have taken any precautions for an upcoming earthquake, like bolting their shelves to the wall or come up with an evacuation plan. Using this idea, we have now found a question that we’re interested in analyzing: are you prepared for an earthquake or not? And now, based on this question and the data that we have, we can see that you can either be prepared (seen above as “true”) or not (seen above as “false”).

Our question: How well can we predict whether or not someone is prepared for an earthquake?

An Algorithm – what’s that?

With our question in tow, we want to design a way for our machine to determine if someone is prepared for an earthquake or not. To do this, the machine goes through a flowchart-like set of instructions. At each fork in the flowchart, there are different answers which take the machine on a different path to get to the final answer. If you go through the correct series of questions and answers, it can correctly identify a person as being prepared. Here’s a small portion of the final flowchart for the San Andreas data which we will proceed to dissect (note: the ellipses on the right-hand side of the flowchart indicate where the remainder of the algorithm lies. This will be expanded later in the chapter):

The steps that we take through the flowchart, or tree make up the classification algorithm. An algorithm is essentially a set of step-by-step instructions that we follow to organize, or in other words, to make a prediction about our data. In this case, our goal is to classify an individual as prepared or not by working our way through the different branches of the tree. So how did we establish this particular set of questions to be in our framework of identifying a prepared individual?

CART, or a classification and regression tree, is one way to assess which of these characteristics is the most important in terms of splitting up the data into prepared and unprepared individuals (Wikipedia 2017b, Breiman et al. (1984)). There are multiple ways of implementing this method, often times with the earlier branches making larger splits in the data, and later branches making smaller splits.

Within an algorithm, there exists another level of organization composed of features and parameters.

In order to tell if someone is prepared for an earthquake or not, there have to be certain characteristics, known as features, that separate those who are prepared from those who are not. Features are basically the things you measured in your dataset that are chosen to give you insight into an individual and how to best classify them into groups. Looking at our sample data, we can see that some of the possible features are: whether or not an individual is worried about earthquakes in general, prior experiences with earthquakes, or their gender. As we will soon see, certain features will carry more weight in separating an individual into the two groups (prepared vs. unprepared).

If we were looking at how important previously experiencing an earthquake was in classifying someone as prepared, we’d say it plays a pretty big role, since it’s one of the first features that we encounter in our flowchart. The feature that seems to make a bigger split to our data is region, as it appears as the first feature in our algorithm shown above. We would expect that people in the Mountain and Pacific regions have more experience and knowledge about earthquakes, as that part of the country is more prone to experiencing an earthquake. However, someone’s age may not be as important in classifying a prepared individual. Since it doesn’t even show up in the top of our flowchart, it means it wasn’t as crucial to know this information to decide if a person is prepared or not and it didn’t separate the data much.

The second form of organization within an algorithm are the questions and cutoffs for moving one direction or another at each node. These are known as parameters of our algorithm. These parameters give us insight as to how the features we have established define the observation we are trying to identify. Let us consider an example using the feature of region. As we mentioned earlier, we would expect that those in the Mountain and Pacific regions would have more experience with earthquakes, which may reflect in their level of preparedness. Looking back at our abbreviated classification tree, the first node in our tree has a parameter of “Mountain or Pacific” for the feature region, which can be split into “yes” (those living in one of these regions) or “no” (living elsewhere in the US).

If we were looking at a continuous variable, say number of years living in a region, we may set a threshold instead, say greater than 5 years, as opposed to a yes/no distinction. In supervised learning, where we are teaching the machine to identify a prepared individual, we provide the machine multiple observations of prepared individuals and include different parameter values of features to show how a person could be prepared. To illustrate this point, let us consider the 10 sample observations below, and specifically examine the outcome, preparedness, with respect to the features: will_occur, female, and household income.

Of these ten observations, 7 are not prepared for the next earthquake and 3 are. But to make this information more useful, we can look at some of the features to see if there are any similarities that the machine can use as a classifier. For example, of the 3 individuals that are prepared, two are female and only one is male. But notice we get the same distribution of males and females by looking at those who are not prepared: you have 4 females and 2 males, the same 2:1 ratio. From such a small sample, the algorithm may not be able to tell how important gender is in classifying preparedness. But, by looking through the remaining features and a larger sample, it can start to classify individuals. This is what we mean when we say a machine learning algorithm learns.

Now, let us take a closer look at observations 1005, 1011, and 1012, and more specifically the household income feature:

All three of these observations are females and believe that the “Big One” won’t occur in their lifetime. But despite the fact that they are all unprepared, they each report a different household income. Based on just these three observations, we may conclude that household income is not as important in determining preparedness. By showing a machine different examples of which features a prepared individual has (or unprepared, as in this case), it can start to recognize patterns and identify the features, or combination of features, and parameters that are most indicative of preparedness.

In summary, every flowchart will have the following components:

1. The algorithm - The general workflow or logic that dictates the path the machine travels, based on chosen features and parameter values. In turn, the machine classifies or predicts which group an observation belongs to

2. Features - The variables or types of information we have about each observation
3. Parameters - The possible values a particular feature can have

Even with the experience of seeing numerous observations with various feature values, there is no way to show our machine information on every single person that exists in the world. What will it do when it sees a brand new observation that is not identified as prepared or unprepared? Is there a way to improve how well our algorithm performs?

Training and Testing Data

You may have heard of the terms sample and population. In case these terms are unfamiliar, think of the population as the entire group of people we want to get information from, study, and describe. This would be like getting a piece of information, say income, from every single person in the world. Wouldn’t that be a fun exercise!

If we had the resources to do this, we could then take all those incomes and find out the average income of an individual in the world. But since this is not possible, it might be easier to get that information from a smaller number of people, or sample, and use the average income of that smaller pool of people to represent the average income of the world’s population. We could only say that the average income of the sample is representative of the population if the sample of people that we picked have the same characteristics of the population.

For example, if we assumed that our population of interest was a company with 1,000 employees, where 200 of those employees make $60,000 each and 800 of them make $30,000 each. Since we have this information on everyone, we could easily calculate the average income of an employee in the company, which would be $36,000. Now, say we randomly picked a group of 100 individuals from the company as our sample. If all of those 100 individuals came from the group of employees that made $60,000, we might think that the average income for an employee was actually much higher than the true average of the population (the whole company). The opposite would be true if all 100 of those employees came from the group making less money - we would mistakenly think the average income of employees is lower. In order to accurately reflect the distribution of income of the company employees through our sample, or rather to have a representative sample, we would try to pick 20 individuals from the higher income group and 80 individuals from the lower income group to get an accurate representation of this company population.

Now heading back to our earthquake example, our big picture goal is to be able to feed our algorithm a brand new observation of someone who answered information about themselves and earthquake preparedness, and have the machine be able to correctly identify whether or not they are prepared for a future earthquake.

One definition of a population could consist of all individuals in the world. However, since we can’t get access to data on all these individuals, we decide to sample 1013 respondents and ask them earthquake related questions. Remember that in order for our machine to be able to accurately identify an individual as prepared or unprepared, it needs to have had some experience seeing some observations where features identify the individual as prepared, as well as some observations that aren’t. This seems a little counterintuitive though. If we want our algorithm to identify a prepared individual, why wouldn’t we show it all the observations that are prepared?

By showing our machine observations of respondents that are not prepared, it can better strengthen its idea of what features identify a prepared individual. But we also want to make our algorithm as robust as possible. For an algorithm to be robust, it should be able to take in a wide range of values for each feature, and appropriately go through the algorithm to make a classification. If we only show our machine a narrow set of experiences, say people who have an income of between $10,000 and $25,000, it will be harder for the algorithm to correctly classify an individual who has an income of $50,000.

One way we can give our machine this set of experiences is to take all 1013 observations and randomly split them up into two groups. Note: for simplification, any observations that had missing data (total: 7) for the outcome variable were removed from the original dataset, leaving 1006 observations for our analysis.

1. Training data - This serves as the wide range of experiences that we want our machine to see to have a better understanding of preparedness

2. Testing data - This data will allow us to evaluate our algorithm and see how well it was able to pick up on features and parameter values that are specific to prepared individuals and correctly label them as such

So what’s the point of splitting up our data into training and testing? We could have easily fed all the data that we have into the algorithm and have it detect the most important features and parameters we have based on the provided observations. But there’s an issue with that, known as overfitting. When an algorithm has overfit the data, it means that it has been fit specifically to the data at hand, and only that data. It would be harder to give our algorithm data that does not fit within the bounds of our training data (though it would perform very well in this sample set). Moreover, the algorithm would only accurately classify a very narrow set of observations. This example nicely illustrates the concept we introduced earlier - robustness - and demonstrates the importance of exposing our algorithm to a wide range of experiences. We want our algorithm to be useful, which means it needs to be able to take in all kinds of data with different distributions, and still be able to accurately classify them.

To create training and testing sets, we can adopt the following idea:

1. Split the 1006 observations in half: roughly 500 for training, and the remainder for testing
2. Feed the 500 training observations through the algorithm for the machine to understand what features best classify individuals as prepared or unprepared
3. Once the machine is trained, feed the remaining test observations through the algorithm and see how well it classifies them

Algorithm Accuracy

Now that we’ve built up our algorithm and split our data into training and test sets, let’s take a look at the full classification algorithm:

Recall the question we set out to answer with respect to the earthquake data: How well can we predict whether or not someone is prepared for an earthquake? In a binary (yes/no) case like this, we can set up our results in a 2x2 table, where the rows represent predicted preparedness (based on the features of our algorithm) and the columns represent true preparedness (what their true label is).

This simple 2x2 table carries quite a bit of information. Essentially, we can grade our machine on how well it learned to tell whether individuals are prepared or unprepared. We can see how well our algorithm did at classifying new observations by calculating the predictive accuracy, done by summing cells A and C and dividing by the total number of observations, or more simply, (A + C) / N. Through this calculation, we see that the algorithm from our example correctly classified individuals as prepared or unprepared 77.9% of the time. Not bad!

When we feed the roughly 500 test observations through the algorithm, it is the first time the machine has seen those observations. As a result, there is a chance that despite going through the algorithm, the machine misclassified someone as prepared, when in fact they were unprepared. To determine how often this happens, we can calculate the test error rate from the 2x2 table from above. To calculate the test error rate, we take the total number of observations that are discordant, or dissimilar between true and predicted status, and divide this total by the total number of observations that were assessed. Based on the above table, the test error rate would be (B + C) / N, or 22.1%.

There are a number of reasons that a test error rate would be high. Depending on the data set, there might be different methods that are better for developing the algorithm. Additionally, despite randomly splitting our data into training and testing sets, there may be some inherent differences between the two (think back to the employee income example above), making it harder for the algorithm to correctly label an observation.

References

Breiman, Leo, Jerome H Friedman, Richard A Olshen, and Charles J Stone. 1984. “Classification and Regression Trees. Wadsworth & Brooks.” Monterey, CA.

Hickey, Walt. 2015. “The Rock Isn’t Alone: Lots of People Are Worried About ‘the Big One’.” FiveThirtyEight. FiveThirtyEight. https://fivethirtyeight.com/datalab/the-rock-isnt-alone-lots-of-people-are-worried-about-the-big-one/.

Wikipedia. 2017a. “Earthquake — Wikipedia, the Free Encyclopedia.” http://en.wikipedia.org/w/index.php?title=Earthquake&oldid=762614740.

———. 2017b. “Predictive analytics — Wikipedia, the Free Encyclopedia.” http://en.wikipedia.org/w/index.php?title=Predictive%20analytics&oldid=764577274.

When Americans had sex, moved in with someone, and so on. Often not average. Far from normal. Read More

Keeping up my yearly blogging cadence, it’s about time I wrote to let people know what I’ve been up to for the last year or so at Mozilla. People keeping up would have heard of the sad news regarding the Connected Devices team here. While I’m sad for my colleagues and quite disappointed in how this transition period has been handled as a whole, thankfully this hasn’t adversely affected the Vaani project. We recently moved to the Emerging Technologies team and have refocused on the technical side of things, a side that I think most would agree is far more interesting, and also far more suited to Mozilla and our core competence.

Project DeepSpeech

So, out with Project Vaani, and in with Project DeepSpeech (name will likely change…) – Project DeepSpeech is a machine learning speech-to-text engine based on the Baidu Deep Speech research paper. We use a particular layer configuration and initial parameters to train a neural network to translate from processed audio data to English text. You can see roughly how we’re progressing with that here. We’re aiming for a 10% Word Error Rate (WER) on English speech at the moment.

You may ask, why bother? Google and others provide state-of-the-art speech-to-text in multiple languages, and in many cases you can use it for free. There are multiple problems with existing solutions, however. First and foremost, most are not open-source/free software (at least none that could rival the error rate of Google). Secondly, you cannot use these solutions offline. Third, you cannot use these solutions for free in a commercial product. The reason a viable free software alternative hasn’t arisen is mostly down to the cost and restrictions around training data. This makes the project a great fit for Mozilla as not only can we use some of our resources to overcome those costs, but we can also use the power of our community and our expertise in open source to provide access to training data that can be used openly. We’re tackling this issue from multiple sides, some of which you should start hearing about Real Soon Now.

The whole team has made contributions to the main code. In particular, I’ve been concentrating on exporting our models and writing clients so that the trained model can be used in a generic fashion. This lets us test and demo the project more easily, and also provides a lower barrier for entry for people that want to try out the project and perhaps make contributions. One of the great advantages of using TensorFlow is how relatively easy it makes it to both understand and change the make-up of the network. On the other hand, one of the great disadvantages of TensorFlow is that it’s an absolute beast to build and integrates very poorly with other open-source software projects. I’ve been trying to overcome this by writing straight-forward documentation, and hopefully in the future we’ll be able to distribute binaries and trained models for multiple platforms.

Getting Involved

We’re still at a fairly early stage at the moment, which means there are many ways to get involved if you feel so inclined. The first thing to do, in any case, is to just check out the project and get it working. There are instructions provided in READMEs to get it going, and fairly extensive instructions on the TensorFlow site on installing TensorFlow. It can take a while to install all the dependencies correctly, but at least you only have to do it once! Once you have it installed, there are a number of scripts for training different models. You’ll need a powerful GPU(s) with CUDA support (think GTX 1080 or Titan X), a lot of disk space and a lot of time to train with the larger datasets. You can, however, limit the number of samples, or use the single-sample dataset (LDC93S1) to test simple code changes or behaviour.

One of the fairly intractable problems about machine learning speech recognition (and machine learning in general) is that you need lots of CPU/GPU time to do training. This becomes a problem when there are so many initial variables to tweak that can have dramatic effects on the outcome. If you have the resources, this is an area that you can very easily help with. What kind of results do you get when you tweak dropout slightly? Or layer sizes? Or distributions? What about when you add or remove layers? We have fairly powerful hardware at our disposal, and we still don’t have conclusive results about the affects of many of the initial variables. Any testing is appreciated! The Deep Speech 2 paper is a great place to start for ideas if you’re already experienced in this field. Note that we already have a work-in-progress branch implementing some of these ideas.

Let’s say you don’t have those resources (and very few do), what else can you do? Well, you can still test changes on the LDC93S1 dataset, which consists of a single sample. You won’t be able to effectively tweak initial parameters (as unsurprisingly, a dataset of a single sample does not represent the behaviour of a dataset with many thousands of samples), but you will be able to test optimisations. For example, we’re experimenting with model quantisation, which will likely be one of multiple optimisations necessary to make trained models usable on mobile platforms. It doesn’t particularly matter how effective the model is, as long as it produces consistent results before and after quantisation. Any optimisation that can be made to reduce the size or the processor requirement of training and using the model is very valuable. Even small optimisations can save lots of time when you start talking about days worth of training.

Our clients are also in a fairly early state, and this is another place where contribution doesn’t require expensive hardware. We have two clients at the moment. One written in Python that takes advantage of TensorFlow serving, and a second that uses TensorFlow’s native C++ API. This second client is the beginnings of what we hope to be able to run on embedded hardware, but it’s very early days right now.

And Finally

Imagine a future where state-of-the-art speech-to-text is available, for free (in cost and liberty), on even low-powered devices. It’s already looking like speech is going to be the next frontier of human-computer interaction, and currently it’s a space completely tied up by entities like Google, Amazon, Microsoft and IBM. Putting this power into everyone’s hands could be hugely transformative, and it’s great to be working towards this goal, even in a relatively modest capacity. This is the vision, and I look forward to helping make it a reality.

Strategy is everywhere in our society. But strategy in practice seems to be a cruel and even silly joke. I learned that the hard way when I went to college long before I ever studied strategy formally. My own “strategy” about how to get through college collapsed virtually the moment I set foot on campus. I was living on my own for the first time and had never been outside of California’s perennial summer weather environment before. I was a poor fit for an East Coast school and didn’t last a full year, getting ill from the cold temperature and transferring out to a California school. At the time, I felt like a failure.

Ensō (c. 2000) by Kanjuro Shibata XX. CC BY-SA 3.0

Like many people of my generation and my socio-economic bracket, my teenage years were eventually consumed by the looming issue of where to go to college. I tried to get the best grades, study hard for the SAT, and make whatever connections I could with alumni to get into colleges I wanted. I applied to many of them, recycling and modifying personal statement letters like the individual payloads and sub-payloads of a MIRV’d nuclear missile. Once I got to college, the clarity and structure that routine provided evaporated. I had to make my own. It was certainly very difficult.

That was a bad first year in general, but not all of my memories are of struggling. In my first year of college, I had a roommate that stayed up until the wee hours of the morning playing computer games. I had a hard time sleeping because I was always hearing the clickety-clack sound of his mechanical keyboard. My memory of that time is hazy. But I do remember my roommate and his games well enough. I struggled to keep up with my economics problem sets, my legal studies essays, and everything else that college required. I also had to somehow maintain a long-distance relationship carried over from high school that was fraying and would later die when I returned to California. And meanwhile, here my roommate was, playing computer games into the late night and wee hours of the morning. Everything I was doing had some sort of externally imposed purpose. But for him it was just fun, natural. A way to pass time and enjoy things. I was too consumed by my own worries back then to care too much about how well he did in his classes. But I did know that he was pretty good at PC games. He devoted a lot of time and energy to it, and as far as I know no one was paying him to do it or giving him a grade for it. It didn’t improve his social status at the college as as far as I could tell, and I recall that it created friction with his girlfriend when it cut into the time he spent with her. This was before E-Sports really became as lucrative of a pro sport as it is today, so I don’t think he got much or any professional benefit out of it either. But yes, forget about him and fast forward for a moment.

The summer after I transferred out, I attended the Boyd conference at the Marine Corps base in Quantico, Virginia. There, I met many people interested in the strategic theories of fighter pilot John Boyd. It put me on a path I’ve traveled for a decade now, studying strategy and writing about for both policy and academic audiences. As a researcher, I’ve tried hard to explain how strategy works. I was motivated by an interest I’ve had since I was young in the way that people and groups make decisions in competitive situations. My parents keep copies of a story I wrote when I was little about wars between colonies of ants and bees (respectively) in my backyard. When the war in Iraq occurred, I remember being shocked, angered, and dumbfounded at the catastrophically inept way that we prosecuted it and the horrifying consequences for our nation, the Iraqis, and the surrounding region. I wanted to understand what happened and think about how America could do better. In the process, I became fascinated with models and representations of strategy and tactics work.

My college BA thesis was on military campaign planning models and command and control. I looked at the debate between different schools of thought about how groups and organizations planned and tried to investigate competing claims about which method was more normatively justified and which method was more descriptively justified. I came to realize that the two things were intertwined. Normative models would be useless if they strayed too far from what we descriptively knew about how people and groups made decisions. And one of the most important descriptive things to consider was how people and groups used information and communicated. My master’s thesis compared models of special operations, information warfare, and deception operations. I tried to see if a composite model that I created to explain how organizations attacked other organizations’ ability to sense, think, and act explained modern conflicts as well as World War II military operations that predated the information era. And as a PhD student I’ve immersed myself in mathematical and computer models of competitive decision-making in a number of domains that are mostly outside of the realm of war or security.

What I’ve learned is that we struggle at understanding how even simple things work, and that struggle shows how much we have to learn about the things that aren’t so simple. And that’s a big problem. If people’s lives – or even just their political fortunes or money – depend on the ideas we have about strategy, we have an heavy ethical burden. Unfortunately American history is replete with too many examples of men and women with big ideas that have led to big disasters. Many of these ideas have something in common: they are grandiose, systematizing if not totalizing, and yet somehow fatally incomplete. As my friend Lynn Rees pointed out a while ago, the people who make these grand plans often see things in their narrow area of expertise quite intensely but see everything else as vague and fuzzy colors. More recently, a writer describing the quirks of Silicon Valley technocrats noted that while they are afraid of superintelligent artificial intelligence, they also seem to be doing the very things (intelligence amplification, hacking, economic optimization) that they fear in a hypothetical superintelligent killer robot:

Such skull-and-dagger behavior by the tech elite is going to provoke a backlash by non-technical people who don’t like to be manipulated. You can’t tug on the levers of power indefinitely before it starts to annoy other people in your democratic society. I’ve even seen people in the so-called rationalist community refer to people who they don’t think are effective as ‘Non Player Characters’, or NPCs, a term borrowed from video games. This is a horrible way to look at the world. So I work in an industry where the self-professed rationalists are the craziest ones of all. It’s getting me down.

That quote resonated with me on a deep level. I’m convinced that we think too much about superintelligent adversaries in general and mold ourselves in that image. Instead, we need to think about the strategies and tactics of how people like my roommate play PC games. The games he played – which if my faulty memory serves me right included first person shooter (FPS) and real-time strategy (RTS) games – didn’t give him any tangible rewards that society valued for continuously honing his skills. It cost him time, money (mechanical keyboards specialized for playing games can be pricey, to say nothing of a nice PC gaming rig), and cut into opportunities to focus on things that society might conventionally value more (grades, friends, a job, etc). But he did it nonetheless. Intrinsic motivations, curiosity, and striving without explicit goals are, after all, something that scientists want to understand in order to build better robots. And games are simple and real human activities involving strategic and competitive interaction that we know that humans actually play, as opposed to the Prisoner’s Dilemma (an abstraction we invented) and geopolitics (too big to easily study as a whole).

Most importantly, studying the more complex games people play reveals that players have strategies of no strategy. In this essay, I’ll try to walk you through what that means. I will weave together, as I do here in this opening, big ideas and questions as well as episodes from my own life and the subjective experiences that I’ve had that inform my research interests, understanding of those questions, and potential answers to them. I will try to consider, in particular, a paradox that has haunted me for as long as I have been studying strategy in all of its forms: strategy is everywhere, but strategy is also nowhere. Our society values strategy, craftiness, Machiavellianism, and nth-level chess to an absurd degree. But we nonetheless seem so remarkably bad at it and our institutions consistently fail at it. What is wrong? What don’t we understand? How can we fix it? Ultimately I leave the answers to these questions up to you, dear reader. What I hope to accomplish here is at least to help you think about them in a way that is less tied to the fantasies of power and rationality that often sadly accompany most discussions of strategy.

The Poverty of Strategy

Strategy is everywhere in our society. But strategy is also nowhere. Businesses have “strategy” for managing competition. Yet this seems to do very little for them in a dynamic and unstable external environment. The Pentagon has “strategy” for winning wars. But we’re going on a decade and a half of inconclusive bloodshed in the Middle East and elsewhere. Policy analysts perpetually talk about having a “grand strategy” for American geopolitics but seem unable to get this strategy through government. And if you don’t have a strategy for convincing a bunch of politicians and bureaucrats, how “grand” really is your strategy?

One possible (if depressing) conclusion to take from this is that strategy is just an illusory abstraction that we have invented to give meaning to that which has none. We use it as a retrospective framing device to explain a complex series of events (of our own making but mostly of external provenance) that we do not understand. So maybe strategic theory is really just an gussied up form of conspiracy theory. We need to impose order on the world and believe that someone, somewhere, knows that the hell is going on. That certainly has a grain of truth to it, but its also too excessively nihilistic. What seems more clear is that the dominant ways of thinking about strategy that we use – which are actually just variations on the same underlying assumptions we have about the world – don’t work. I will explain at length why it does not work and I have already hinted as much in this section and the one that opened this essay.

But before I explain further, I would like you to temporarily take your mind out of the realm of “serious” things like war, politics, business, foreign policy, or geostrategy. As a PhD student I have learned the hard way that the manner in which I thought about serious things was profoundly unserious and un-scientific.

When I thought about areas of life where strategy decided something big and important, I often did so without an open mind. I took for granted the things that were written in textbooks and the things that practitioners said. I would often discover upon closer investigation that these things I took for granted had an at best minor relationship to reality. The elegant theoretical model in the textbook was a just-so story that was destroyed by “out-of-sample” data. The memoir of the general was a mixture of some ground truth but far more self-serving selective memory and self-promotion. And the cutting-edge of research in academic journals often was little better and sometimes much, much worse.

These big ideas — as well as plenty of small and medium-sized ones —  can become a trap because they can separate you from seeing the obvious. So leave all of that behind for a moment and think purely about your own life experiences as an individual. You do not have to be an great political leader, a decorated soldier, a captain of industry, or really anyone important. Suppose that your experiences are “data” that should be counted and measured just as much as any of the aforementioned figures’ histories. And so imagine that you are trying to explain to a neutral observer about the how and why of major life decisions you have made or how you perform an intricate professional skill that you have spent years and years mastering. You could try to explain it as the outcome of a series of explicit plans you have made (“I knew I was going to do N, which requires K, and so on”) or a policy/rule that you adopted (“My logic is to always do N in situations of K”). You could try but you would likely fail.

For example, you did not know in advance that you were going to meet your husband at that bar, and perhaps he was your second or third choice but grew on you when you got to know him. Maybe you did not know in advance either that you would stay together at all given the tests that your relationships endured even when it became serious. On a different tack, perhaps you could say that it was your goal to become president of the fraternity and you took the actions that were contextually and pragmatically necessary to reach that goal. But that doesn’t tell you how you balanced your goal of being fraternity president with other competing imperatives, such as the need to eat, sleep, attend classes, maintain a romantic relationship with your girlfriend, and work part-time. And what if you were on the fence about wanting to be president and the sudden and unexpected exit of an formidable rival pushed you to do it? Or that you may have never originally wanted to become president at all and you ended up doing it because you failed at something else important to you? And what about situations where you did not have a goal at all and managed to somehow, through tinkering, curiosity, and exploration, arrive at a major achievement that you would later retroactively claim was the result of a pursuable goal you always had?

The same explanatory problems occur when we think about the aforementioned ‘serious’ topics described a few paragraphs up. We always tend to leave something out when we think about strategy, perhaps because it is simply too large and multifarious to be any one thing independent of our own subjective beliefs about what form of strategy matters and where strategy can be found. When you try to explain in retrospect how you fought decades ago in that particular battle, you will leave critical details out unintentionally and describe how you fought vaguely and incompletely. When people read about the strategy of a particular figure in history, they also are the helpless victim of the historian or the social scientist’s need to make the figure’s strategy coherent and linear enough to fit into a coherent narrative. He was bound to do X because of his overriding idea of how the struggle was to be waged, an idea that the researcher has often retroactively read into a pattern of behavior with no logical organization or the contradictory documentary evidence available from the historical figure’s personal papers. And to what degree can a particular leader’s success really be attributed to her own strategic genius as opposed to the opponent’s mistakes, the quality of her subordinates, or the favorable geostrategic position of her country? Maybe we might even say that we cannot talk about strategic success or failure at all without discussing the human genetic and evolutionary heritage and the benefits and limitations it offers anyone engaged in a competitive interaction? The purpose of the study of history and the pursuit of better theoretical and empirical knowledge of strategy is that study is supposed to rectify this problem. But have they been successful at finding the answer?

Yes and no. Disciplines that study strategy are products of the Enlightenment and its urge to formally represent, systematize, and organize the world’s knowledge in great chains of being and tree-like hierarchies. The hope is that this yields time-invariant principles of how the world works. Perhaps they are not to be mechanically applied in action. They are, as the caveat goes, only a guide to professional thinking that must be done contextually. All models are wrong but some are useful. Yada yada. You have heard many of these cautions — or less charitably, handwaves — before.  But there is still some expectation that theories and concepts provide meaningful guidance due to their capturing of regularities. Things that exist outside of individual human minds and survive long after particular humans are dead. Ideas about strategy are also products of a secular but nonetheless mystical belief that everything serves a clearly definable, teleological end. So strategic knowledge aims to formalize, to discover and lay out the rules, and most importantly to make the complex simple. That has proven to be a tremendously successful way of doing research on and thinking about competitive interaction in many cases. But it has flaws. I will briefly list them here before moving on.

How do we really know that any of these ideas are correct? Much of the most relevant aspects of human behavior are beyond human retrospection and conscious self-awareness. And the behavior of human experts in particular things are also not really well-described by rationality or rule-following. But rational behavior is a perennial explicit and implicit assumption in the study of strategy, and qualitative structures and rules are a big part of what produces it. Creative strategic behavior can certainly be approximated by conceptual descriptions, mathematical models, or computer algorithms. Perhaps we can even build computer programs that can perform the tasks humans can or perform the tasks human can in a way that is biologically plausible. But the urge to formalize, to say that “___ complex thing is like ___” is also a trap. We believe that we can somehow separate ourselves and our own subjectivity from the models and maps that we use. But that’s a lie that we tell ourselves that will end up as our undoing. Financial models, for example, describe how decisions are aggregated by markets. But those decisions are also based on financial models and other ideas that people have about the market. It’s a self-licking ice cream cone that is being licked by a self-licking ice cream cone that is being licked by another self-licking ice cream cone, and so on and so forth.

Even one of my intellectual heroes, the polymathic researcher Herbert Simon, falls into this trap while trying to explain away objections to his model of human problem-solving (which depends on problems being well-structured). Simon says that ill-structured problems are just well-structured problems that haven’t been structured yet. OK, but that isn’t really helpful, especially when some problems lack some sort of optimal structure to be discovered and instead depend on the problem-solver being willing to juggle an number of different images of it and pragmatically apply them as need be. Worse yet, the strategy field has also gotten bogged down in a stupid and inconclusive fight between fans of the rational-technical and emergent approaches to strategy. The rational-technical school holds that strategy is the product of an deliberate, top down process of problem setting, problem analysis, planning, and execution. The emergent school instead argues that the strategy emerges from the bottom-up from informal collaborations, improvisations, and hacks. But this distinction would have been utterly foreign to the premodern world. They would say it is both — but also neither.

The major image of strategy held in the ancient world was one of steering a path between order and uncertainty, melding both detached forethought with a constant probing of the front lines to adapt and change the ultimate design as need be. Strategy had to ‘spread out’ according to particular circumstances of competitive interaction and the form that the military-political organization took at any particular point in time. Strategy occurred at all levels of the organizational hierarchy. This idea perhaps still survives today in some parts of the world. The idea that one develops a feel for the configuration or propensity of things and shapes the opportunity that arises from them is a prominent aspect of Chinese philosophy and to some extent martial thinking in other Asian civilizations. The American strategist Boyd expanded it by fusing this idea with modern Western philosophical and scientific ideas, arguing that the purpose of strategy is to isolate the opponent from the ability to perceive and influence the world while increasing one’s own efficacy at doing so. And you could even argue that this idea is present in entities ranging from terrorist cells to Silicon Valley startups. So why don’t many of the academics studying strategy get it?

Some of them do. But many of them also still are chasing the unified field theory that will make everything make sense. The problem comes from the same shared assumption held by both rational-technical and emergent schools: a vaguely triangular organization of strategy, tactics, and some kind of collection of vertical and horizontal mediating layers exist, strategy is some kind of formalizable and discoverable thing arrived at either through deliberation and/or improvisation, and a singular objective representation of it can be found via scholarly research and analysis.

The debate between what became known as the ‘emergence’ school and the planning or ‘design’ school, began fairly inclusively (Mintzberg called for an opening up of the definition of strategy to include patterns, perspectives and ploys, in addition to planning and positioning). However, things became increasingly polarized in the first half of the 1990s. In so doing, they reflected one of the modernity’s key tenets: ‘objective representationalism’; the idea that the purpose of knowledge is to represent, without logical contradiction, the ‘ways things really are’ or the linear, functional causes of actions. Given this, finding opposing schools of thought is problematic for any field seeking to develop as a modern science.

Despite the particular biases about what I think strategy is that I display in this essay, I urge you not to take them as the gospel truth. So it may be appealing to say, that for example, the Chinese game of Go is a more realistic way of thinking about strategy than the Western game of chess because of its emphasis on opportunistic thinking and acting and paying mind to an evolving balance of time, space, and knowledge. And I have come to believe that this claim is, to some extent, true. But taking in that contention uncritically would be to repeat the mistake that the quoted excerpt describes. Barring tremendous advances in how we can know about the world of Copernican proportions, we are going to have to settle with the uneasy recognition that there is no one correct, Platonic idealization of strategy. There is only the subjective means by which we use to study it, learn from it, describe it, and make it ourselves. This is why studying how people play strategic and competitive games is important. Economists study abstract representative agents that solve abstract mathematical models that are neither true nor false. That certainly has its purpose and utility, and I’m not going to take it away from them. But real people play games. And the complexities of how and why they play them is often surprising even to someone like me that studies real-world strategies of states and armies.

The Game(s) of Life

I’m not alone in thinking that games are important. So did Simon. For all of Simon’s faults, he also ingeniously saw the game of chess as a metaphor for the problem of a democratic society. Simon, like many 20^th century progressive intellectuals, thought that Western society was faced with an false choice between the unlimited freedom to choose imagined by economists fascinated with self-interested agents in a market-driven liberal capitalist society and the top-down behavioral control imagined by psychologists, sociologists, and authoritarians that either lamented or celebrated the passive and controllable nature of the individual in a mass society. Simon wanted a world in which people with limited capacity to choose could handle the burden of choice without having their choices induced into them like rats in a Skinner box. So he looked at games like chess, in which experts could use clever heuristics, adaptive learning, and efficient collection and storage of knowledge to play a game that was too big to solve by planning everything out beforehand.

The political problem that Simon sought to solve still exists today. And it has gotten worse. We face so many competing demands on our attention and resources and so many things that we must juggle. And so I strongly believe that RTS games like Starcraft are what Simon would study today if he was a young researcher, as they present a particularly useful subjective map of our experiences in an information-saturated and increasingly fast-paced life. This is perhaps why RTS games are being studied by Google DeepMind as the next games for its artificial intelligence programs to conquer and RTS games are studied by both cognitive scientists and computer scientists in the same way chess used to be. But if one looks at the history of chess research, it is questionable whether scientists will really grasp the essence of PC strategy games even if they quantify it or build an mechanical player capable of beating a human. What might they fail to capture? It’s hard to put into words (for reasons that ought to be clear by now), but I’ll do my best anyway.

This particular story starts, like many important events in my life lately, with a conversation I had with my wife. One day late last year, I was flying back to California with my wife to visit my family. I was reading a book on Go written by an sociologist. My wife told me about a Go master that had reached such a state of strategic excellence in playing the game that he didn’t need to think about playing Go or even care about winning or losing. It reminded me of an article written by David Auerbach about game-playing artificial intelligence programs. Auerbach pointed out that in games like Go whose state spaces and branching factors were too high for move-by-move board evaluation, the computer had a “strategy without a strategy.”

[Research opens] the possibility that our process of analogy making may be even less rational and more stochastic than we suspect, and that the deep archetypes we match against in our brain might bear far less relationship to reality than we might think. Underneath our apparent rationality may lie neurobiological processes that look considerably closer to random trial and error. In this view, human creativity and randomness go hand in hand. The power of randomness is amply visible in new approaches that have finally enabled computers to play games like Go, Hex, Havannah, and Twixt at a professional level. At the heart of these approaches is an algorithm called the Monte Carlo method which, true to its name, relies on randomized, statistical sampling, rather than evaluating possible future board configurations for each possible move. For example, for a given move, a Monte Carlo tree search will play out a number of random or heuristically chosen future games (“playouts”) from that move on, with little strategy behind either player’s moves. Most possibilities are not played out, thus constraining the massive branching factor. If a move tends to lead to more winning games regardless of the strategy then employed, it is considered a stronger move. The idea is that such sampling will often be sufficient to estimate the general strength or weakness of a move.

This sort of “meta-strategy” is just playing out semi-random games and sampling the possibilities. But it works better than “strategic” board evaluation methods that attempt to accurately evaluate the strength of prospective board positions. My wife’s comments also reminded me not just of Go but the popularity of computer fighting games like Street Fighter or Super Smash Bros that are now played semi-professionally and professionally online as a sport. Whereas Go eventually became highly professionalized and formal due to mass media coverage of play, the rise of professionalized computer game playing made the informal and even aesthetic aspects of competitive gaming more important. When describing Starcraft RTS play, professional E-Sportscaster Sean “Day9” Plott clinches exactly why all of the informal elements are so important:

Despite the fact that these games function in drastically different ways and demand completely different skill sets, the expert players, the players who consistently win, always share a single commonality: they play comfortably with a marginal advantage. The marginal advantage embodies the notion that one cannot, and should not, try to “win big.” In a competitive setting, the strong player knows that his best opponents are unlikely to make many exploitable mistakes. As a result, the strong player knows that he must be content to play with just the slightest edge, an edge which is the equivalent to the marginal advantage. More importantly, a one-sided match ultimately carries as much weight as an epic struggle. After all, the match results only in a win or a loss; there are no “degrees” of winning. Therefore, at any given point in a game, the player must focus on making decisions that minimize his probability of losing the advantage, rather than on decisions that maximize his probability of gaining a greater advantage. In short, it is much more important to the expert player to not lose than it is to win big. Consequently, a regular winner plays to extend his lead in a very gradual, but very consistent manner.

In other words, the kind of games being played here prize those who are able to maintain an advantage over time. They do not admit one obviously good strategy or tactic for any particular problem. The individuality, style, and character of the player is inseparable from that player’s skill or mechanical button-mashing. And most importantly a player must deal with a stream of large, small, and medium-scale decisions rather than any particular “cooperate or defect” choice. RTS games are perhaps the best example of Plott’s “marginal advantage.” In a typical RTS, players control a base full of buildings, workers, and soldiers. The goal is to destroy all of the enemy’s buildings. While this may sound simple enough, this description belies the task of the player. The player must control groups of soldiers in combat, from simple and slow-moving infantry soldiers and tanks to fast-moving recon scouts and jets. Some of these units have unique abilities that must be harnessed in a tactical group. Strong “micro” control over these units is essential to maximize their effectiveness and keep them alive. On the other hand, making units depends on gathering resources and constructing buildings that keep them supplied, give them new abilities, and recruit them to build the army. Strong “macro” is necessary to build and manage the player’s force and the military-industrial complex that supports it.

In between are other functions such as scouting the map to discover the enemy’s whereabouts and infer the opponent’s intention to perform a future operation. Or deciding whether or not to expand one’s resource production to different corners of the map. All of these tasks  would be a pain to do in a turn-based game like Civilization . It is a nightmare to do in real-time, which Starcraft necessitates. Top players are capable of hundreds of actions per minute, can flexibly allocate their attention to different spatial and functional parts of the game as need be, and also are skilled at developing and executing strategic plans (which are valid for only a few minutes at a time ) quickly and effectively. And amidst all of this frenetic action and task-switching, players must be able to follow through with short to long-term plans and keep track of the state of play. But this is not really what necessarily makes the game interesting.

Consider the simple fact that players do not directly “move” pieces as in chess. Players instead direct autonomous units or groups of units to do things. The behavior of these units is very simple but also unpredictable, necessitating that players continuously arrange, re-arrange, and manage their autonomous units over the course of the game. Players can automate their behavior to a limited degree but have to be constantly watching and waiting to step in. Starcraft ’s complexity also at least partly reveals how easy to infer a greater rationality post-hoc to explain a complex strategy or tactic. Upon closer analysis , a plan is often only a weakly determinative resource for guiding action, and it is mostly used post-hoc for explanatory purposes. “I planned to do X and so I did it.” As I say here and there throughout this essay, I think that the experience of playing an RTS is a much more useful representation of the kinds of decisions we make and challenges we face in today’s information-saturated, unstable, and perhaps “liquid” modern world. RTS tests our ability to impose coherence on it despite the multitude of task-switching and task balancing across spatial, temporal, and functional scales.

So to sum things up, Go, computer fighting games, RTS games, and FPS games are all interesting to me for roughly similar subjective reasons. First, players’ strategies only vaguely resemble the “strategy” of game theory or military strategy. Everything else might be thought of as a kind of heuristic circle of action that owes far more to the vagaries of memory, perception, and intuition than game-theoretic reasoning or deliberate campaign or operation planning. Second, these games all have large and mostly informal communities of players that have developed an elaborate “metagame” of strategies through decentralized collaboration, cooperation, and play. Many of them passionately argue, analyze, and test these strategies and tactics with a rigor that peer review in academia often lacks and a creativity that many MBA schools and war colleges often do their best to kill before students graduate. They do it despite widespread societal prejudices agains t the idea that playing computer games will amount to anything in life. Like my college roommate in the anecdote that opened this essay, their intrinsic motivation is unconventional but also powerful and meaningful. So  all of these games are about, to some degree, a confluence of what Simon studied in chess and my wife mentioned when talking about Go.

They are both about a conceptual model of how people produce creative and effective strategic behavior in adversarial and difficult circumstances as well as lessons in why the best people who do it are those that can let go of all of the things that get in the way of them playing their best – including even the desire to avoid loss. I’m convinced that modern computer games tell us a lot about competitive interactions in the world that we live in now, a world that forces us to do too many things at once over the short, medium, and long term. That’s my subjective image of the world that I hope to pursue in my PhD research.  And as my wife pointed out, the most challenging aspect of explaining the manner in which people play complex games in general is that the fact that they are playing to “win” does not tell us much about them. It doesn’t explain the cognitive mechanisms behind play or really the strategy selection and execution. But more broadly a basic preference to win can be held even if the person in question plays as if they have no earthly attachments to hold them down – including the desire to win. They have Auerbach’s strategy of no strategy, and are able to balance the formalized ideas of what they will do before they enter the game with the ways in which they become whatever the game requires at any particular moment. That is why competitive games are not just useful for understanding strategy, but also essential to better understand our own humanity and purpose in life.

The Humanity in Strategy

I have come to believe, as Simon did in linking his idea of bounded rationality to normative ideas about democracy and society, that the way that we make decisions cannot be de-contextualized from the human and social stories that we tell ourselves about ourselves. That is why this essay is not just about the problem of understanding how people make strategy, it is also partly a story of my life and the story I have told myself about it.

Come 13 July of this year (2017), it will be 10 years to the day that I embarked on this journey by attending the Boyd conference at the Alfred M. Gray Research Center on Marine Corps Base Quantico in 2007. What have I learned in the time since I took my first step on the road I would travel for a decade? What I’ve learned is that the answer to – or at least a way of generating better questions about – many of the puzzles I wanted to solve was sitting in that college dorm room that first year of college. If your theory of strategy cannot explain the way in which my roommate played computer games, it is probably not going to live up to its full explanatory potential in terms of providing insight about how nations fight wars, businesses dominate the market, or social movements make lasting change.

That’s not to say that studying the way that my roommate played computer games will provide immediate, actionable insights about those domains or even good theoretical models. I’m also not saying that you should give up studying things like how nations fight wars or businesses dominate the market in favor of dropping everything to study my old roommate and his PC game strategies and tactics. But my wife’s comments triggered another realization about the relevance of such games that became clear when we later watched a movie about the Go master Wu Qingyuan’s life and times. Wu was truly devoted to the game of Go and played through even the chaos and destruction of World War II. He did not know for sure what would come of it, he only had the game as an fixed constant as everything else in the world he knew was destroyed by war.

Strategy is, at the end of the day, not just a way of attaining your desired ends or a theory about how people make competitive decisions. It is a way of life and the story of our lives. Researchers have a responsibility to get it right because important decisions are made based on what people believe strategy to be. But the broader reward for studying it is to reflect on our own individual struggles as human beings to strategically make our own way through a finite, random, and cruel world and to make meaning out of that finite, random, and cruel world. If we do not think about and reflect on that struggle and the strategies we develop in response, we are unlikely to accomplish much of importance, whether we are generals fighting wars or ordinary people simply trying to get by. Strategy of the kind that makes people feel smart and powerful is everywhere — for a consultant’s fee. Bona fide results are far less common than the deluge of promised results from them. But the kind of strategy that arises from merely a will to become something other than a passive vessel for fate to toss around resides potentially within each and every one of us. And by thinking about strategies of others we are more likely to discover it in ourselves.

Cycling can do a lot for you: it can keep your heart healthy, it can connect you to a new community, it gets you outside and in (mostly) fresh air.  It also happens to do a few more  things that are all key ingredients for a happy mind:

It's Aerobic 

In a recent study done on clinically depressed participants, aerobic exercise such as cycling was shown to increase their mood levels to a more positive state. The amount of time required for participants to exercise was only 30 minutes. Which is a considerably short period of time for some really wonderful benefits. 

It gives you all the happy Chemicals

There are two chemicals in your brain that get a major boost from a good e-bike ride and you've probably heard of them before.

-Serotonin: While we exercise, this mood stabilizing neurotransmitter is released. Depleted levels of serotonin can lead to depressive moods, so giving yourself a boost is crucial for staying happy. 

- Dopamine: As the "Pleasure" chemical. It's around for all those moments when you feel really good such as when you're in love, or after a really great bike ride. 

It's Connects you to a Community 

The relationships that surround you play a huge part in your mental health. Feeling connected to a strong support system is key to navigating your way out of depression. Taking a bike ride with friends, or even striking up a conversation with new people about e-bikes can be a huge determining factor in your sense of well-being. 

It encourages savoring

 Savoring is the use of thoughts and actions to increase the intensity, duration, and appreciation of a positive experience. When you're riding a bike on a beautiful day, your ability to appreciate your surroundings and the experience are so much higher than when you are driving in a car. The act of Savouring is a psychological tool that we as humans often perform when we are experiencing gratitude. They pretty much go hand in hand. Go for a bike ride, feel the gratitude, feel happy.  

I visited Jaybird at IFA 2016 in Berlin, took a look at their Freedom and X2 headsets and was pretty sure I wanted a Freedom headset. It's just tiny and extremely light. But it did not make much sense to test it then, since Jaybird wasn't shipping here yet.

Fast forward to last week and I received an email from the agency offering me test samples. I thought about it for a bit and then replied asking for both. Not only the Freedom but also the X3, successor to the X2. As it turned out that was a smart move.

Enter the Freedom. Isn't this thing tiny? It ships without the ear gels attached and you have to customize it with one of three sizes of gels, or one of three sizes of memory foam which provide a better seal. And then you can add one of four sizes of fins, that sit inside your ear and push the head of the earpiece in, so it never comes out, no matter what you do.

You have to take your time with this process. Only when you achieve a seal, you will get the full sound experience. If your in-ear-phones sound tinny, chances are it is not the headset but the fit. The good news is that it is very easy to swap gels on these Jaybird headsets, unlike most other designs. So I played with different gels but I could not get them to sound well.

Somewhat disappointed I tried the X3 and they immediately resonated with me. I stepped up from the medium size gel to the large one and boooom, there was the bass. Add two medium size fins and I had the perfect fit. As it later turned out, the Freedom headset fit just perfect into small ears, while my somewhat larger than normal ears needed the X3. So the red Freedom became the Lady headset, and for the first time ever we found an an in-ear-headset she likes.

Both headsets are sweat-proof and you can wear the wire over the ear or casually just hanging out of your ear. The box contains two clips that let you manage the length of the cable so the headset sits firmly on your head with the wire behind your neck. Great for workouts.

Both headset connect over Bluetooth to up to two devices at the same time. So they need power and have batteries that last for eight hours. You charge them via 500 mA and 5 V USB. The Freedom has an interesting design. Half of that battery capacity is located in the in-line controller together with three buttons and the mic. The other half is in a tiny box that has a microUSB connector and five pins. You clip it to the controller to get to eight hours or you use the headset without, rendering 4 hours of playback. While you are using them, you can recharge the tiny box separately. If you buy spare adapters, you can have several of them pre-charged for long flights or you can attach one while you charge the other one. The X3 is simpler. The controller contains the eight hour battery and you need to attach a clip that connects the USB wire to the pin holes on the controller.

The headset are pre-configured with an equalizer setting that provides some "loudness" by raising the bass. You can program them any way you want them to sound through the MySound app. A different sound is just a tap away. There are downloadably profiles and you can also manually set the equalizer any way you want.

These are great products if you want a headset for sports, that is customizable to your needs. Just know that you will need the X3 for larger ears and the Freedom for tiny ears.

Celebrating Mother Language Day In Open Source

Mozilla volunteer Deepak Upendra interviews in Telugu language, taken with permission of those being interviewed. (Photo by Dyvik Chenna,CC BY-SA 4.0)

With a goal to reach, and listen to diverse and authentic voices, the insights phase of our plan for a Diversity and Inclusion strategy for Participation has, so far, been an inspired journey of learning. To mark International Mother Language Day, and to celebrate the theme of building sustainable futures we wanted to share our research work for D&I at Mozilla.

It became apparent very early into our research, that we needed to prioritize the opportunity for people to be interviewed in their first-languages, and together with a small and passionate team of multi-lingual interviewers we have been doing just that — so far in French, Spanish, Albanian, Hindi, Telugu, Tamil and Malayalam. With a designed process including best practices, and an FAQ — and leveraging a course we developed last year called ‘Interviewing Users for Mozilla’ we’ve been able to mobilize even beyond our core group.

To better tell the story of our work, we interviewed some of our interviewers about their experiences:

Liza Durón, Interviews in Spanish

Liza is a Full Stack Marketer and Ethnographer from Mexico who volunteers here time at Mozilla in many areas, including as Club Captain for Mexico’s Mozilla Club.

On barriers faced by non-English speakers in open communities:

“People slow down their participation because they don’t fully understand English, so they don’t want to make mistakes or to be “ridiculous” if they say something wrong. Which is nonsense because we’re an open community and it is supposed that we are able to explain everyone if they need so. People tend to be frustrated at not being able to communicate themselves widely and that’s when tolerance is diminished, we judge ourselves internally and we decide to turn away from overcoming those barriers and asking for support. “

On how people can bridge the linguistic barriers in Open Source:

Every task they do, document it in their first language and their in English. If we only care about doing it in Spanish, it won’t figure globally and if we only do it in English, it will only be available for more people.

Kristi, Interviews in Albanian

Kristi is chairwoman of Open Labs Hackerspace in Tirana, Albania, a Mozilla Tech Speaker and current Outreachy Intern at Mozilla.

On why first language research is important:

I have witnessed that interviews in first language People are so free to express and the results are even more real and it’s clearer to understand.

On how this method of research can lead to greater D&I in communities like Mozilla:

(by embedding translators in community spaces/events) More people will be included since they will feel more comfortable to be part of the community and won’t have to say : “I can not attend I don’t understand what they say and I can not speak English.”

Bhagyashree Padalkar, Speaks Marathi, Interviews in Hindi

Bhagyashree is a Data Scientist, actively involved with the Fedora Operations and Diversity Team and Outreachy Intern at Mozilla. She is working on both data analysis and first-language interviews with our D&I team.

On biggest barriers non-English speakers face in the open source world in general, and Mozilla in particular:

(Even though I am a confident English Speaker) I feel like I have to think twice before I speak up because any small mistake I make would not only make me more vulnerable to next, but also make the community members feel that I am not capable enough — or in some cases, even cloud their impressions of other Indians.

On the experience of interviewing in first-language:

I can definitely say that this research will help in identifying critical issues and barriers non-native English speakers face while contributing to FOSS. Overall, while conducting first language interviews, I have felt contributors able to connect more easily when speaking in their native language as this reduces their pressure a lot, makes them think a lot less about technical things like finding the right words to express themselves in English and helps the process feel more like a friendly conversation than a grilling round of interview.

The results of first-language interviews are proving an important opportunity to learn more about the experience of our community, but also how to better at include non-English speakers in future. Thank you to all of our interviews, and community members taking time to talk with us. And happy Mother Language Day!

Save

Save

Share

World Wide Web Consortium (W3C), Feb 26, 2017

Web annotations have been a longtime dream of many, but for many it was fool's gold - tantalizingly close, but ultimately worthless. We've seen a slew of efforts - web post-its, side-bar wikis, dual-column pages, and more. Now the World Wide Web Consortium (W3C) has come out with recommendations, including "a structured model and format, in JSON, to enable annotations to be shared and reused across different hardware and software platforms." Will this be the standard that makes the difference? Image: ShowMe

This week on News 1130 radio in Vancouver, I spoke about these tech topics for Wired Wednesday with Ben Wilson:

• Alien particles from outer space are wreaking low-grade havoc on personal electronic devices (source)
• eSight 3: Augmented Reality glasses that can help the legally blind see (source)
• Smart Socks: Internet connected socks you probably don’t need (source)

Listen here

The post Wired Wednesday: Alien particles, eSight 3 & Smart Socks appeared first on johnbiehler.com.

According to TheNextWeb, researchers in Munich have found evidence to suggest that few people want to look at the selfies of others, but they love sharing their own. The findings of a survey of 238 people were published in Frontiers in Psychology in a January article titled “The Selfie Paradox: Nobody Seems to Like Them Yet Everyone Has Reasons to Take Them.”

77% | Take selfies at least once a month
49% | Receive a selfie at least once a week
90% | Think others’ selfies are self-promotion
46% | Think their own selfies are self-promotion

Translation | People enjoy taking selfies but don’t like looking at other peoples’ selfies. (The researchers say that other cultures than Germany may have more accepting attitudes towards selfies and that further study is required.)

Observation | Is this surprising? They are called selfies. It’s why Apple put a camera on both sides of the iPhone.

For some reason, selfies are of great interest to researchers and the publications that write about research. Bottomline. There are two types of people in the world: People who like taking photos of themselves and people who love to hear themselves complaining about people who take photos of themselves.

Ken Case, CEO of the Omni Group, wrote today about a new detail of its upcoming OmniOutliner 5 software. In addition to the traditional Pro version, OmniOutliner will also come in a new Essentials version.

In OmniOutliner’s new Essentials edition, your entire focus is on your own content: there are no distracting sidebars or panels. You can choose to work in a window or in a distraction-free full-screen mode, selecting from a set of beautiful built-in themes. As you write, you’ll be able to see some key statistics about your content so you can track progress towards your goals. But our goal is to help you focus on your content and whatever task you’re working on—not on the tool you’re using.

With the Essentials edition, we’ve lowered OmniOutliner’s entry price from $49.99 to an extremely affordable $9.99. And since we want our upgrade price from Essentials to Pro to be $49.99, the new list price for Pro has been lowered to $59.99:

While Case's post references OmniOutliner for Mac specifically, he later confirmed in a tweet that OmniOutliner Essentials would be coming to iOS as well.

This announcement represents a shift in direction for the Omni Group. The company's traditional offerings have included Basic and Pro versions of each program, but the Basic version has historically not been anywhere near the price point of this upcoming Essentials edition. It will be interesting to see if this new approach expands to Omni's other apps over time.

Today's news is the second major shift in pricing strategy the Omni Group has made in the past year. Last September saw news that they would begin offering software as free downloads in the App Store, with an In-App Purchase to unlock full functionality. This change in pricing model made it possible to offer free trials, such as with OmniGraffle 7; trials are currently not possible on the App Store under the paid up front model.

OmniOutliner 5 for Mac is currently in a public test that can be downloaded here. More information about the Essentials version is available here.

Support MacStories Directly

Club MacStories offers exclusive access to extra MacStories content, delivered every week; it’s also a way to support us directly.

Club MacStories will help you discover the best apps for your devices and get the most out of your iPhone, iPad, and Mac. Plus, it’s made in Italy.

With technology continually evolving and changing, so does its vocabulary. The enterprise world is littered with jargon, one of the buzzwords du jour being “digital transformation (DT)” which I’m sure you’ve heard of by now. But what does it mean? It’s like Dan Ariely’s humorous comment on big data, “everyone talks about it, nobody really knows how to do it, but everyone thinks everyone else is doing it, so everyone claims they are doing it.”

At a high level, DT is very easy. It’s simply the adoption of digital technologies to transform your business. So just choose the digital technology you want, and use it to change how your business operates. Done!

Why Digital Transformation Fails

Sounds easy. But it’s not. Numerous sources report that roughly 70% (ranging from 66% to as high as 84% via Forbes) of the DT initiatives fail. Clearly, it can’t be as simple as deploying a digital technology (given such high failure rate), even though that could pose challenge in some cases.

So why is DT so difficult? The reason is because that a true transformation of your business requires more than just the adoption of new technology. DT usually starts with some kind of technology upgrade, but that’s only the first step. Subsequently, it requires changes in your business processes, your employee and leadership behavior, and ultimately your corporate culture. Changing technology might be easy, but changing the people, processes and culture is hard.

The challenge of DT is not a digital or even a technological problem; it’s a business transformation problem. If we try to understand why DT fails, the most common causes of failure boil down to the following 4 categories of reasons.

Technology:

1. Using outdated technologies
2. Failure to integrate with legacy or other digital systems
3. Believing that it’s only a technology problem

People:

4. Lack of clarity and vision
5. Lack of leadership support
6. Too much top down imposition without grass root support
7. Lack of a digitally savvy workforce

Process:

8. Silo effort that didn’t engage the broader stakeholders
9. Process misalignment
10. Not agile enough for faster innovation

Culture:

11. Short term thinking
12. Not customer centric
13. Too little cross-functional collaboration

Since these are failure modes, they are all important. As it only takes one broken link to break the whole chain, any one of these failure modes could undermine the success of your entire DT initiative. So every one of them must be addressed, which is a lot for businesses to undertake.

But here’s the bright side: Although all the common failure modes must be addressed, not all of them need to be addressed at once. And if you are embarking on the DT journey, not all of them need to be addressed at the beginning. So which ones should you focus on first?

Upon analyzing the natural dependency among these failure modes, there are only 3 that must be addressed from the get-go. And I will explain this with the video blog below.

1) Customer Centricity

A customer-centric strategy is imperative, simply because every business needs customers. Moreover, in an increasingly service-oriented subscription economy, every business is striving to retain their customers, because not only is the competition more intense, the switching cost for consumers is often minimal. While this is a given from a business standpoint, customer centricity is equally as important for your digital transformation (DT) initiative for several reasons.

It’s easier to rally for support when you have a customer-centric strategy, precisely because it makes business sense. Very few people would argue against serving your customers. A well thought-out customer-centric strategy could easily win both leadership and grassroot support. You still need to sell the strategy within your enterprise, but it shouldn’t be a difficult sell.

It’s also less challenging to create processes that are aligned across different departments with a customer-centric mindset. Traditional business processes are often created to optimize some business KPIs while meeting their operating constraints. However, different departments and teams often operate under disparate constraints and have unique set of KPIs. Consequently, their processes are typically misaligned because they were created irrespective of one another. Customer-centricity serves as the glue that binds different departments and teams together. It helps you create processes that are aligned with giving your customers a great experience.

When all your processes are aligned, it facilitates cross-functional collaboration. At the very least, the processes are not adding friction that could hinder collaboration. Although this doesn’t automatically drive collaboration, it certainly makes it easier when there is a business need to do so. When that happens, your DT is suddenly no longer a siloed effort.

Finally, a customer-centric mindset fosters long-term thinking because most businesses want to have loyal (long-term) customers, especially in a subscription economy.

2) A Clear Vision

Despite the simplicity of the definition, digital transformation (DT) could be confusing because it’s different for every company. Myriads of digital technologies are on the market, which can change any one of the multitude of business operation within your enterprise.

For example, DT for one company may be using iPads (a digital technology) to scale onboarding of new employees (a perfectly valid HR function). It could also be using social media (another digital technology) to engage and support your customers throughout their customer journey (a marketing and customer support operation). It could even be using big data (yet another class of digital technology) to predict sales, using IoT and augmented reality to improve customer experience, or anything in between.

DT can mean many different things, so you must have a clear vision of what DT means for your enterprise. Which digital technology are you using? And which part of your business operation are you trying to improve with these technologies initially? Most importantly, what business outcome are you trying to achieve? As alluded earlier, a customer-centric mindset could help you answer some of these questions and shape your vision.

Armed with a clear vision of what DT means for your business makes it even easier to garner both leadership and grassroot support. And if you are a leader, a clear vision probably means that you are bought in and committed to supporting this change.

3) The Right Technology

Since digital transformation (DT) almost always starts with a technology upgrade, it is important to choose the right technology at the beginning. Having a clear DT vision that is customer-centric helps you choose the digital technologies to realize your vision, but there are other factors to consider.

Certainly, the right technology must have all the functionality required by your specific DT project. It must meet all the security, reliability, and legal compliances for your enterprise, and must built to scale with robust technologies that last. This is unique to each business, but there are two elements that are often overlooked at the beginning which may impact the long-term success of your DT initiatives.

First, the right technologies should be easily integrated into with the rest of your company’s technology ecosystem. And that includes both your legacy systems and other newly adopted digital systems. Keep in mind that when you kick off a digital initiative, your core business will still be running on your legacy system. Failing to integrate with these systems means your DT project will remain a siloed effort. While DT initiatives often start small in one area of the company, it must permeate throughout your enterprise to achieve lasting transformation.

Second, the right technologies should be simple and intuitive to use. It should be so intuitive that even your non-digital workforce should be able to pick it up and immediately carry out rudimentary functions without much training. Of course, training and education will always be required to reach proficiency.

The key is to make sure that the learning curve does not offset the efficiency gain from the use of your new digital technology for the “digital novice,” even at the very beginning. Furthermore, when there is residual efficiency gain, even during the adoption phase of your DT project, innovative minds within your enterprise will have the cognitive surplus to innovate and be more agile.

Transformation means lasting change

Digital transformation is a journey. It always starts with the adoption of digital technologies, but it must also change the people, process and the culture to be truly transformative. It typically begins as a siloed technology project, but must permeate throughout your enterprise. Although digital transformation can seem difficult, concentrating on the above focuses at the very start will help pave the road for long-term success.

*This article originally appeared on CMSWire.

*Image Credit: Pexels and tpsdave.

Michael Wu, Ph.D. is Lithium's Chief Scientist. His research includes: deriving insights from big data, understanding the behavioral economics of gamification, engaging + finding true social media influencers, developing predictive + actionable social analytics algorithms, social CRM, and using cyber anthropology + social network analysis to unravel the collective dynamics of communities + social networks.

Michael was voted a 2010 Influential Leader by CRM Magazine for his work on predictive social analytics + its application to Social CRM. He's a blogger on Lithosphere, and you can follow him @mich8elwu or Google+.

What is this?

This app demonstrates how to create a reusable component and how to inject it into the browser. This app displays a batting order for a baseball team using a #player-card component. This component displays information relating to each player on a baseball team – picture, name, position, and handedness. A #player-card can also be configured with additional functionality using optional tags. The app also shows some of the ways sort can be used, and how to choose specific records out of a list of records.

You can play with this example in your browser here.

Page Layout

Containers

I want to break the page down into two sections: one for the active lineup and the bench players, and one for players on injured reserve.

commit @browser
  [#div class:"container" children:
    [#div #active class:"lineup" text:"Batting Order"]
    [#div #inactive class:"lineup" text:"Bench"]]
  [#div #IR class:"lineup IR" text:"Injured Reserve"]

Active Lineup

The first column drawn should be the active batting order. While I could have specified all the text and contents of each player in this block, note that I used two tags, #player-card and #moveable, whose contents and behavior get defined later. Since every player listed is going to have the same information, #player-card lets me drop the tag in and define all the HTML and content later, which is done in the Player Cards section after this one.

search @session @browser
  player = [#player not(#bench) not(#injured) lineup]
  active = [#active]

bind @browser
  active.children += [#div #lineup children: [#player-card #moveable player sort: lineup]]

Bench Players

These are the bench players. Note that #player-card is used again, saving me the work of having to define all the same html and content that’s used in the active lineup. The big difference here is the ordering of the players. Whereas the players in the lineup have a deliberate and specific order (which makes sense for things like a batting order), I don’t need a specific order for the bench players. I do, however, want to know how many there are and make sure they render in the same order each time, so I sort by the player variable to get an index, n. Each player gets assigned an index, which is how I sort the bench players, and also set player.lineup to that index so they get numbered 1, 2, 3, and so on.

search @session @browser
  player = [#player #bench lineup]
  inactive = [#inactive]
  n = sort[value:player]

bind @session @browser
  player.lineup := n
  inactive.children += [#div #lineup children: [#player-card #benched sort:n player]]

Injured Reserve

These are the injured reserve players. This section is functionally identical to the bench player section, except it gets merged into the #IR section on the page. There’s only one player on the IR and no functionality exists to move him elsewhere, because he is a jerk.

search @session @browser
  player = [#player #injured not(#bench) lineup]
  IR = [#IR]
  n = sort[value:player]

bind @session @browser
  player.lineup := n
  IR.children += [#div #lineup children: [#player-card sort:n player]]

Player Cards

This is where the magic happens. Every time this finds #player-card in the browser, it will make a #div for each player and spit out a player card. It checks to see if the player has a nickname as well, and just leaves a space between the first and last names if there isn’t. It’s worth mentioning that because I want this to be as general a template as possible, a handful of architectural decisions were made to facilitate that. In the sections that draw each of the three lists, I use the search parameters there to select the specific players I want and inject those player cards. In the Roster Data, all the players have a lineup attribute even though the bench and IR players have an empty string as the value. If you’re good at predicting which reusable parts you’ll need, you can implement these sorts of things from the outset, or you can figure out where they need to be as you go along and refactor them into your code as you work.

search @browser @session
  container = [#player-card player]
  player = [#player firstname lastname position bats lineup photo]
  middle = if player.nickname then " \"\" "
           else " "

bind @browser
  container <- [#div player class: "lineup-position" children:
    [#div class: "bat-number" text: lineup]
    [#div class: "player-info" children:
      [#img class: "player-photo" src: photo]
      [#div class: "player-text" children:
        [#div class: "name-line" children:
          [#div class: "position" text: position]
          [#div class: "first-name" text: firstname]
          [#div class: "middle-name" text: middle]
          [#div class: "last-name" text: lastname]]
        [#div class:"bat-hand" text:"Bats: "]]]]

Buttons

Move Up

The active roster also features a cool way to use tags. Since I want to be able to reorder my active lineup, each #player-card there is also tagged #moveable. This checks to see if a #player-card is #moveable and adds a child #div to it with a #move-up-btn, unless that player is already at the top of roster and can’t move up any further.

search @browser @session
  container = [#div #moveable player]
  not(player.lineup = 1)

bind @browser
  container.children += [#div #move-up-btn player class: "ion-chevron-up"]

It’s like hashtag inception. Just as the #moveable tag let Eve know to add a #move-up-btn, this block adds another layer of functionality by giving that button some behavior. In this case, when a #move-up-btn is clicked, Eve captures who the specific clicked-player is, finds whoever is one space above them in the lineup, and switches their places.

search @browser @event @session
  [#click element: [#move-up-btn player: clicked-player]]
  above-clicked = [#player lineup: clicked-player.lineup - 1]

commit
  clicked-player.lineup := clicked-player.lineup - 1
  above-clicked.lineup := above-clicked.lineup + 1

Move Down

This block is the mirror of the move up buttons. If a #player-card is #moveable, and not at the bottom of the lineup, which is what the count is checking, then a child #div gets added with a #move-down-btn.

search @browser @session
  container = [#div #moveable player]
  not(player.lineup: count[given: [#player not(#bench) not(#injured)]])

bind @browser
  container.children += [#div #move-down-btn player class: "ion-chevron-down"]

Once again the reciprocal of the previous section, when a #move-down-btn is clicked, Eve captures the specific clicked-player, finds the player one space below them in the lineup, and switches their places.

search @browser @event @session
  [#click element:[#move-down-btn player: clicked-player]]
  below-clicked = [#player lineup: clicked-player.lineup + 1]

commit
  clicked-player.lineup := clicked-player.lineup + 1
  below-clicked.lineup := below-clicked.lineup - 1

Remove from Lineup

If a player is #moveable, it means they’re in the active lineup and should be able to be removed from the active lineup and sent to the bench. This simply looks for any #moveable players and adds a #deactivate button to them.

search @browser @session
  container = [#div #moveable player]

bind @browser
  container.children += [#div #deactivate player class: "ion-log-out"]

This gives #deactivate its behavior. The clicked-player is sent to the bench and is stripped of their lineup order. All the players who were below them on the lineup get moved up a spot so that there aren’t gaps in the numbering.

search @browser @event @session
  [#click element: [#deactivate player: clicked-player]]
  players-below = [#player lineup > clicked-player.lineup]

commit
  clicked-player += #bench
  clicked-player.lineup := ""
  players-below.lineup := players-below.lineup - 1

This block takes care of an edge case for #deactivate. Because the previous block finds all the players-below the clicked-player, if the player is at the bottom of the lineup then there are no players-below and the search block fails, preventing the button from doing anything. This makes sure you can move the ninth batter off the lineup onto the bench.

search @browser @event @session
  [#click element: [#deactivate player: clicked-player]]

commit
  clicked-player += #bench
  clicked-player.lineup := ""

Add to Lineup

This adds an #activate button to the bench players so we can add them to the active lineup, but only if there are fewer than nine batters already in the lineup.

search @browser @session
  container = [#div #benched player]
  active-players = if c = count[given: [#player not(#bench) not(#injured)]] then c else 0
  active-players != 9

bind @browser
  container.children += [#div #activate player class:"ion-log-in"]

This gives #activate its behavior. When an #activate button is clicked, Eve finds out how many active players are in the lineup then adds the clicked-player and assigns them the next number in the lineup.

search @browser @event @session
  [#click element: [#activate player:clicked-player]]
  active-players = if c = count[given:[#player not(#bench) not(#injured)]] then c else 0
  active-players != 9

commit
  clicked-player -= #bench
  clicked-player.lineup := active-players + 1

Roster Data

Our sample roster data.

commit
  [#player firstname:"Kenny" lastname:"DeNunez" position:"P" bats:"R" lineup:3 photo:"http://i.imgur.com/kaRnA7R.png"]
  [#player firstname:"Hamilton" lastname:"Porter" nickname:"Ham" position:"C" bats:"R" lineup:1 photo:"http://i.imgur.com/7C678n2.jpg"]
  [#player firstname:"Timmy" lastname:"Timmons" position:"IF" bats:"R" lineup:8 photo:"http://i.imgur.com/JLHupGR.png"]
  [#player firstname:"Bertram" lastname:"Grover Weeks" position:"IF" bats:"R" lineup:2 photo:"http://i.imgur.com/mfIMIy6.png"]
  [#player firstname:"Alan" lastname:"McClennan" nickname:"Yeah-Yeah" position:"IF" bats:"R" lineup:6 photo:"http://i.imgur.com/ZyLzCDn.jpg"]
  [#player firstname:"Benny" lastname:"Rodriguez" nickname:"The Jet" position:"IF" bats:"S" lineup:9 photo:"http://i.imgur.com/UOywuNz.jpg"]
  [#player firstname:"Scott" lastname:"Smalls" position:"OF" bats:"R" lineup:5 photo:"http://i.imgur.com/eBZ2m17.jpg"]
  [#player firstname:"Michael" lastname:"Palledorous" nickname:"Squints" position:"OF" bats:"R" lineup:4 photo:"http://i.imgur.com/q8KKRz6.jpg"]
  [#player firstname:"Tommy" lastname:"Timmons" nickname:"Repeat" position:"OF" bats:"R" lineup:7 photo:"http://i.imgur.com/QPzSCGy.png"]
  [#player #bench firstname:"Thelonius" lastname:"Mertle" position:"IF" bats:"L" lineup:"" photo:"http://i.imgur.com/XDA0ftH.jpg"]
  [#player #bench firstname:"George Herman" lastname:"Ruth" nickname:"Babe" position:"P" bats:"L" lineup:"" photo:"http://i.imgur.com/kep7Unm.jpg"]
  [#player #bench firstname:"Hercules" lastname:"Mertle" nickname:"The Beast" position:"PR" bats:"S" lineup:"" photo:"http://i.imgur.com/WOwMn5c.jpg"]
  [#player #injured firstname:"" lastname:"Phillips" position:"IF" bats:"R" lineup:"" photo:"http://i.imgur.com/Qvxya5C.jpg"]

Styles

The app needs a good bit of CSS to organize the page sections and various buttons as well as stylize the player cards.

.container  {
  display: flex;
  flex-direction: row;
  user-select: none;
  font-size: 20px;
  text-transform: uppercase;
  text-align: center;
  overflow: scroll;
  height: 1000px;
  border-bottom: 1px solid #555;
  flex: 1 1 auto;
}

.IR {
  width: 515px;
  margin-top: 30px;
  flex: 1 0 auto;
}

.lineup {
  display: flex;
  flex-direction: column;
  font-size: 20px;
  text-transform: uppercase;
  text-align: center;
  margin-right: 50px;
  position: relative;
  flex: 1 0 515;
  width: 515px;
  min-width: 515px;
  overflow: scroll;
}

.lineup-position {
  list-style: none;
  display: flex;
  flex-direction: row;
  align-items: center;
  margin-top: 15px;
  position: relative;
}

.bat-number {
  order: 1;
  font-size: 40px;
  font-weight: bold;
  color: #b4b4b4;
  margin-right: 15px;
  width: 50px;
}

.player-info {
  display: flex;
  flex-direction: row;
  margin: 0px 0px;
  padding: 0px 0px 0px 0px;
  height: 85px;
  width: 450px;
  background: #ffffff;
  border: 1px solid #555;
  border-radius: 8px;
  order: 2;
  overflow: hidden;
}

.name-line {
  display: flex;
  flex-direction: row;
  margin: 10px 10px;
}

.position {
  font-size: 14px;
  font-weight: bold;
  margin-right: 8px;
  padding-top: 2px;
  height: 16px;
}

.first-name {
  font-size: 16px;
  text-transform: uppercase;
  height: 16px;
}

.middle-name {
  font-size: 16px;
  text-transform: uppercase;
  height: 16px;
  font-weight: 600;
  white-space: pre;
}

.last-name {
  font-size: 16px;
  text-transform: uppercase;
  height: 16px;

}

.player-photo {
  height: 85px;
  width: 85px;
  border-right: 1px solid #555;
}

.bat-hand {
  font-size: 14px;
  height: 14px;
  text-align: left;
  margin: 10px;
}

.ion-chevron-up {
  position: absolute;
  top: 2px;
  right: 15px;
  font-size: 24px;
  cursor: pointer;
}

.ion-chevron-down {
  position: absolute;
  bottom: 2px;
  right: 15px;
  font-size: 24px;
  cursor: pointer;
}

.ion-log-out {
  position: absolute;
  right: 15px;
  color: #e65b3c;
  font-size: 24px;
  cursor: pointer;
}

.ion-log-in {
  position: absolute;
  right: 15px;
  transform: scaleX(-1);
  color: #009ee0;
  font-size: 24px;
  cursor: pointer;
}

@media (max-width: 1848px) {

.container  {
  flex-direction: column;
  border-bottom: none;
  height: auto;
  flex: 0 0 auto;
}

.IR {
  width: 515px;
  margin-top: 0px;
}

.lineup {
  display: flex;
  font-size: 18px;
  margin-right: 0px;
  flex: 0 0 auto;
  width: 415px;
  min-width: 415px;
  min-height: 100px;
  margin-bottom: 20px;
}

.lineup-position {
  margin-top: 12px;
}

.bat-number {
  font-size: 30px;
  margin-right: 15px;
  width: 50px;
}

.player-info {
  height: 45px;
  width: 400px;
}

.name-line {
  margin: 5px 8px;
}

.position {
  font-size: 10px;
  margin-right: 8px;
}

.first-name {
  font-size: 12px;
}

.middle-name {
  font-size: 12px;
}

.last-name {
  font-size: 12px;
}

.player-photo {
  height: 45px;
  width: 45px;
}

.bat-hand {
  font-size: 10px;
  margin:  5px 8px;
}

.ion-chevron-up {
  top: 0px;
  right: 15px;
  font-size: 16px;
}

.ion-chevron-down {
  bottom: 0px;
  right: 15px;
  font-size: 16px;
}

.ion-log-out {
  right: 15px;
  font-size: 16px;
}

.ion-log-in {
  right: 15px;
  font-size: 16px;
}

}

@media (max-width: 1200px) {

.container  {
  flex-direction: column;
  border-bottom: none;
  height: auto;
  flex: 0 0 auto;
}

.IR {
  width: 515px;
  margin-top: 0px;
}

.lineup {
  display: flex;
  font-size: 18px;
  margin-right: 0px;
  flex: 0 0 auto;
  width: 100%;
  min-width: 150px;
  min-height: 100px;
  margin-bottom: 20px;
}

.lineup-position {
  margin-top: 12px;
}

.bat-number {
  font-size: 30px;
  margin-right: 0px;
  width: 0px;
}

.player-info {
  height: 55px;
  width: 100%;
}

.name-line {
  margin: 2px 8px;
  margin-top: 5px;
  flex-wrap: wrap;
}

.position {
  font-size: 8px;
  margin-right: 5px;
}

.first-name {
  font-size: 10px;
}

.middle-name {
  font-size: 10px;
}

.last-name {
  font-size: 10px;
}

.player-photo {
  height: 55px;
  width: 55px;
}

.bat-hand {
  font-size: 10px;
  margin:  0px 8px;
}

.ion-chevron-up {
  top: 7px;
  right: 8px;
  font-size: 12px;
}

.ion-chevron-down {
  bottom: 6px;
  right: 8px;
  font-size: 12px;
}

.ion-log-out {
  right: 8px;
  font-size: 12px;
}

.ion-log-in {
  right: 8px;
  font-size: 12px;
}

}

Michael Geist, Feb 25, 2017

Michael Geist writes about this year's annual misrepresentation of the state of copy protection and media in Canada by the the International Intellectual Property Alliance (IIPA), a lobby group that represents the major lobbying associations for music, movie, software, and book publishing in the United States. In particular, he focuses on three areas:

• The state of Canadian Piracy, which the IIPA reports as rising, when in fact the Business Software Alliance’ s annual report last showed Canada at its lowest software piracy rate ever 
• The notice-and-notice system, which the IIPA says is not receiving full compliance from ISPs, and which hurts licensed services, when in pact there is nearly full compliance by ISPs, and licensed services are earning strong returns in Canada
• Fair dealing, which the IIPA has attacked on several grounds, but which consistent with fair dealing regimes around the world, and are more stringent than many, including fair use in the United States

As Canada routinely states every year, "Canada does not recognize the 301 watch list process. It basically lacks reliable and objective analysis. It’ s driven entirely by U.S. industry."

Rhea Kelly, Campus Technology, Feb 25, 2017

This is just something I want to keep handy for when I talk to people who already have a Kaltura system running. It seems like a pretty easy way to make a lot of learning resources. Or course the quality and value might vary, but creating something is infinitely better than creating nothing.

Alan Levine, CogDogBlog, Feb 25, 2017

Non-disposable Assignments (NDAs, though he agrees a better acronym is needed) are assignments that ase seen by more than just the student and the person grading them. They can be thought of as open educational resources, but the status as OERs connotes qualities that may not be there. The challenge of NDAs is to create these assignments in such a way that they are actually non-disposable, and not just disposable assignments published in an open way. "It takes a lot of effort to move past the first impulse of writing ones that sound like they are answering a question or a series of questions. Those have an odor of 'disposable-ness'."

Celeste, the successor to 2013’s excellent multiplayer game TowerFall, is set to come to the Nintendo Switch.

Vancouver-based developer Matt Thorson revealed the news in a gameplay trailer posted on YouTube. Thorson, as well as his studio’s co-founder Noel Berry, initially revealed Celeste back in July 2016. While the pair have been relatively silent lately on the game’s development, they frequently stream portions of the game’s development on Twitch.

Celeste is an expanded, upgraded version of Celeste Classic, a game Berry and Thorson developed for the PICO-8 in just four days as an experiment.

The game features more than 250 stages that take place in a variety of settings, including an abandoned city, ancient ruins and cliff-filled country side. The game’s pixelated graphics, which look very similar to TowerFall’s, and gameplay, are inspired by the simplistic yet challenging SNES and NES era of gaming.

Celeste is set to be released later this year for the PlayStation 4, Nintendo Switch and Windows PC. The game is set to be available on March 3rd.

The post Vancouver-based TowerFall developer’s next game, Celeste, is coming to Nintendo Switch appeared first on MobileSyrup.

The specs sheet for Samsung’s upcoming Galaxy S8+ handset appears to have been revealed by prolific mobile tipster Evan Blass.

Blass tweeted an image that includes a laundry list of specifications consumers can expect from the new plus-size flagship. Among them: a 6.2-inch Quad HD+ Super AMOLED display (though the sheet specifies it’s 6.1-inch with rounded corners), IP68 water and dust resistance, wireless charging support and an iris scanner.

The specs also note there will be AKG-tuned earphones included with the device.

The chipset is not included in the list of specs, though previous leaks have indicated it will be the Snapdragon 835. Backing that up, according to this specs list, is 4GB of RAM and 64GB of internal memory with support for external MicroSD cards.

As for the camera package, the rear-facing shooter is a 12-megapixel dual pixel unit, while the front-facing camera is 8-megapixel.

Additionally, the image specifies a few almost bizarrely obvious points, such as “Android operating system” and “4G LTE capable,” as well as noting support for Samsung Pay and Samsung Knox.

The release date for the Samsung Galaxy S8 and S8+ is expected to arrive on February 26th at Samsung’s Mobile World Congress event. Previous rumours have indicated it will be unveiled at a March 29th event in New York City and hit the shelves mid-April 2017.

Source: Evan Blass

The post Samsung Galaxy S8+ specs revealed in new leak appeared first on MobileSyrup.