Skip to content

Commit

Permalink
Merge pull request microsoft#84 from MicrosoftDocs/repo_sync_working_…
Browse files Browse the repository at this point in the history
…branch

Confirm merge from repo_sync_working_branch to live to sync with https://github.com/microsoftdocs/live-share (branch master)
  • Loading branch information
lostintangent committed Jun 15, 2018
2 parents a5ca7e5 + 80f24d2 commit 7165752
Show file tree
Hide file tree
Showing 4 changed files with 144 additions and 2 deletions.
Binary file added .DS_Store
Binary file not shown.
120 changes: 120 additions & 0 deletions docs/reference/use-cases.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
---
title: "Common Use Cases - Visual Studio Live Share | Microsoft Docs"
description: "An overview of the use cases that developers are commonly leveraging Visual Studio Live Share for."
ms.custom:
ms.date: 05/21/2018
ms.reviewer: ""
ms.suite: ""
ms.technology:
- "liveshare"
ms.topic: "reference"
author: "lostintangent"
ms.author: "joncart"
manager: "AmandaSilver"
ms.workload:
- "liveshare"
---

<!--
Copyright © Microsoft Corporation
All rights reserved.
Creative Commons Attribution 4.0 License (International): https://creativecommons.org/licenses/by/4.0/legalcode
-->

# Common Use Cases

The primary goal of Visual Studio Live Share is to enable developers to collaborate with each other more easily (e.g. using their own highly-customized IDEs, being able to investigate ideas independently), without introducing any opinion about when and how to do it (e.g. which communication tool to use, the "right" software methodology or SCM workflow). This way, your tools can support interactions that occur **naturally**, and as **frequently** as needed, but in a way that **compliments** how you already prefer to work.

This document highlights some use cases that Visual Studio Live Share can be used for, and describes how well we currently support them, and ways we plan to optimize them further (based on feedback!). If you're using Live Share for something that isn't already covered below, or you think we can do better to support a specific use case, please [let us know](https://github.com/MicrosoftDocs/live-share/issues/new).

* [Quick Assistance](#quick-assistance)
* [Pair Programming](#pair-programming)
* [Mob Programming](#mob-programming)
* [Coding Competitions / Hack-A-Thons](#coding-competitions--hack-a-thons)
* [School Group Projects](#school-group-projects)
* [Developer Streaming](#developer-streaming)
* [Interactive Education](#interactive-education)
* [Peer Mentoring / Onboarding](#peer-mentoring--onboarding)
* [Team Brown Bags](#team-brown-bags)
* [Classroom Lectures](#classroom-lectures)
* [Code Reviews](#code-reviews)

## Quick assistance

When you run into an issue (e.g. trying to resolve a bug, setting up your environment), you can use Live Share to instantly seek assistance from another peer. In many cases, it isn't immediately clear what context the person providing help will need, and therefore, Live Share helps by making it simple to provide access to your entire project, and if/as needed, incrementally share more (e.g. a local server, read-only terminal). No need to send code snippets and/or error messages back-and-forth!

Additionally, since Live Share allows you to share your active debug session, without requiring "guests" to install any of the necessary platforms SDKs (e.g. Node.js, Go, .NET Core) or tooling extensions, it can help you get resolution faster, and prevent "doesn't repro on my machine" situations. Live Share allows you to share debug state with others, for any programming language or runtime environment (e.g. Kubernetes, React Native app) and so regardless what you need help with, you can share it!

## Pair Programming

One of the most commonly used scenarios for Visual Studio Live Share is "pair programming": two or more developers, working together on a shared task, with the goal of sharing knowledge, increasing team cohesion, and potentially, product quality. The exact look-and-feel of pair programming can differ significantly between teams and situations, depending on the following (among others):

1. The scope of the "task" being collaborated on (e.g. a task, a user story)

1. The expected duration of the collaboration session (e.g. two minutes, an hour, full-time, once a week, TBD)

1. The number of people involved (e.g. two, the entire team)

1. The role of each participant (e.g. "driver", observer/reviewer, subject matter expert)

1. The proximity of participants (e.g. co-located in the same building, across the world)

Live Share was designed to be agnostic to all of the aforementioned concerns, and instead, strives to support pair programming that is completely "opportunistic" and catered to your situation. That said, unlike two developers sharing a single keyboard and screen, Live Share enables a form of pair programming that allows developers to work on a shared goal, without removing their individual autonomy or environment preferences. You can work independently, or together, allowing each participant to bring their own thought process to the collaboration.

To fully support pair programming, and allow each "guest" to perform any action that would be necessary to operate independently, we have work on the roadmap to continue increasing the context and capabilities that are shared in a Live Share session: tasks ([#40](https://github.com/MicrosoftDocs/live-share/issues/40)), build output ([#48](https://github.com/MicrosoftDocs/live-share/issues/48)), guest-driven debugging ([#32](https://github.com/MicrosoftDocs/live-share/issues/32)). Let us know which of these experiences are important to you!

To break this use case down even further, the following items represent forms of pair programming that we've observed folks using Live Share for:

### Mob Programming

[Mob programming](https://en.wikipedia.org/wiki/Mob_programming) (or swam programming) is essentially pair programming, but with more than two people. Therefore, all of the benefits of Live Share for pair programming apply equally as well. Additionally, some teams do "swarming" on an as-needed basis (e.g. the team rallying around a firedrill) as opposed to full-time.

Currently, Live Share supports up to five guests within a session, which may or may not accommodate your team size. However, this is something we plan to increase (for various use cases), and are looking for feedback on ([Vote 👍 Here](https://github.com/MicrosoftDocs/live-share/issues/229))

### Coding Competitions / Hack-A-Thons

Coding competitions and hack-a-thons are effectively short-term, single-task variations of mob programming. The members of the team, and their current role, are also potentially dynamic. Since this use case is typically also time-sensitive, the ability to collaborate in real-time without needing to adopt an entirely new tool, and the ability to work together, without being restricted to a single screen or keyboard, can go a log way in increasing velocity.

### School group projects

School group ends up looking a lot like mob programming, where multiple students are working together, and can transition seamlessly between focusing on a single task, or working on separate tasks concurrently.

### Developer Streaming

Developer streaming (via Twitch or Mixer) has become a compelling new form of education. While Live Share isn't meant to replace their broadcasting platforms (though we've heard the request!), it does provide a means for the host to pair program with one or more guests, and then stream that interaction. This way, viewers can potentially learn more by seeing the natural interaction and thought process of two or more developers, who could even be working together in entirely separate operating systems and IDEs!

## Interactive Education

Generally speaking, Live Share seeks to assist developers in sharing knowledge amongst their team. Education is a fundamental use case for Live Share, and it supports this particularly well by allowing each participant to interact with the codebase being collaborated on, as opposed to simply watching a screen. Everyone learns in subtlety different ways, and therefore, by providing independence to a "student", they are able to take advantage of the instruction being given, without needing to sacrifice their ability to explore their own ideas along the way.

### Peer Mentoring / Onboarding

When introducing a developer to a new codebase, feature area, technology, etc. you can use Live Share to walk them through the project (using `Follow Mode`), such that they can follow along with you, but from within their own personal IDE. Since Live Share allows "guests" to independently navigate the project (e.g. opening a file, performing a `Peek Definition`), they can follow allow, but also, perform quick explorations as needed (e.g. "Hmm, what does this function do?").

### Team Brown Bags

Team brown bags are effectively like peer mentoring, but presented to an entire team, and potentially, more focused on socializing generally useful knowledge, as opposed to onboarding support and/or helping with a specific task.

### Classroom Lectures

When instructors are teaching a lesson, they can use Live Share to share their project with students, instead of simply presenting their screen. This allows the entire class to follow along with the teacher, while being able to interact with the project on their own. Additionally, the teacher can ask individual students to assist in solving a particular portion of the lesson (e.g. "Which method should we call here?"), which can help in the social aspects of the class, without requiring students to walk up to the front of the room, or even be physically present in the same room (e.g. online courses).

## Code reviews

PRs are a powerful way to collaborate with others, but typically represent the completion of a task (excluding "WIP" PRs), and the desire to merged it in. Many times, the feedback that is given in a PR could easily have been given earlier, and therefore, there's potentially value for teams to easily and continuously seek advice from their peers, as opposed to waiting until they "complete" a task to ask.

Since Live Share allows you to instantly share your project with others, it can be used to enable "informal"/ad-hoc code reviews, where instead of asking for help, you're simply seeking input to ensure your direction and/or approach aligns with others. This can potentially help subsequent PRs complete quicker, and definitely helps socialize knowledge across the team.

Additionally, since Live Share allows you to share an arbitrary directory, you can use it to perform code reviews, even if you're not currently using version control (though you should!), or if your team doesn't use PRs (E.g. you do trunk-based development).

*Note: Live Share doesn't currently share source control diffs, which is a critical piece of context when using it for code reviews. This is on our roadmap, and any feedback on priority is greatly appreciated ([Vote 👍 Here](https://github.com/MicrosoftDocs/live-share/issues/36)).

## See also

- [Language and platform support](platform-support.md)
- [Connectivity requirements for Live Share](connectivity.md)
- [Security features of Live Share](security.md)
- [All major bugs, feature requests, and limitations](https://aka.ms/vsls-issues)
- [All feature requests and limitations](https://aka.ms/vsls-feature-requests)

Having problems? See [troubleshooting](../troubleshooting.md) or [provide feedback](../support.md).
1 change: 1 addition & 0 deletions docs/toc.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@
## [Connectivity](reference/connectivity.md)
## [Language Support](reference/platform-support.md)
## [Extension Support](reference/extensions.md)
## [Use Cases](reference/use-cases.md)
## [Linux install details](reference/linux.md)
## [Release Notes](reference/releases.md)
# Resources
Expand Down
25 changes: 23 additions & 2 deletions scripts/linux-prereqs.sh
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,19 @@ echo "will attempt to install for you. Note you may be prompted for your admin (
echo "password during the installation process."
echo ""

#openSUSE - Has to be first as apt is aliased to zypper
if type zypper > /dev/null 2>&1; then
echo "(*) Detected SUSE (unoffically/community supported)"
echo ""
sudo zypper -n in libunwind libcurl[0-9] libopenssl1_0_0 libicu libuuid1 krb5 libz1 gettext gnome-keyring libsecret-1-0 desktop-file-utils xprop
if [ $? -ne 0 ]; then
echo "(!) Installation failed! Press enter to dismiss this message."
read
exit 1
fi

# Debian / Ubuntu
APT=$(which apt 2>&1)
if type apt > /dev/null 2>&1; then
elif type apt > /dev/null 2>&1; then
echo "(*) Detected Debian / Ubuntu"
echo ""
sudo apt install -yq libunwind8 liblttng-ust0 libicu?? libuuid1 libkrb5-3 zlib1g gnome-keyring libsecret-1-0 desktop-file-utils gettext apt-transport-https x11-utils
Expand Down Expand Up @@ -113,6 +123,17 @@ elif type pacman > /dev/null 2>&1; then
exit 1
fi

#Solus
elif type eopkg > /dev/null 2>&1; then
echo "(*) Detected Solus (unoffically/community supported)"
echo ""
sudo eopkg -y it libunwind liblttng-ust libicu curl openssl zlib gnome-keyring libsecret gettext desktop-file-utils xprop
if [ $? -ne 0 ]; then
echo "(!) Installation failed! Press enter to dismiss this message."
read
exit 1
fi

#If no supported package manager is found
else
echo "(!) We are unable to automatically install dependencies for this version of"
Expand Down

0 comments on commit 7165752

Please sign in to comment.