DEV Community: Ian Jennings

A super easy way to participate in Hacktoberfest (New for '22!)

Ian Jennings — Tue, 27 Sep 2022 16:05:47 +0000

Hacktoberfest is a yearly event to encourage people to contribute to open source in October. It's a celebration of community, learning and giving back. Hacktoberfest is a great opportunity to learn what contributing is all about, meet a new developer community, and maybe even earn some prizes along the way.

If you're a beginner it can be difficult to get started with open-source. Sometimes it's hard to onboard with new technology. Even once you're familiar with the repo, tags like "#good-first-issue" might have been completed by someone else.

Thankfully this year, Hacktoberfest is counting documentation as a valid contribution!

Documentation is a great way to contribute to repositories. Often developers don't prioritize their readmes and tutorials. They'll contain bugs, errors, be confusing, poorly formatted, etc. How many times have you come across incorrect or outdated docs yourself?

Documentation is hugely important to open source. Every developer that gets started with a new project needs to read the docs. Yet it's not a priority for most developers. From the 2017 GitHub survey:

According to 93% of respondents there is a "pervasive problem" in the open-source community with incomplete or outdated documentation. Yet 60% of contributors surveyed said they rarely or never contribute to documentation.

Seems like a big problem right? Well this Hacktoberfest, you can help by making some of your own contributions to open-source documentation.

Note that if you'll likely need to become familiar with markdown to work with .md files. Don't worry, it's easy and you can learn it in a few minutes.

Easy ways to contribute to Hacktoberfest documentation

Format the repository readme. Often times the project readmes are a loose collection of thoughts, without headings, titles, or any kind of formatting. Study that markdown guide and spruce it up!
Elaborate on installation steps. Developers often write very short setup steps, sometimes just a list of shell commands without explanation. You can help improve the readme by noting specific package versions, adding links to 3rd-party documentation, and explaining the setup process in plain english
Fix bugs in code samples. Every readme has bugs, even those created by huge companies. Try making use of all the code samples in the readme. It's likely something won't work or a step will be missed.
Enhance the readme with screenshots and videos. - Working on a front-end repo or CLI? Add screenshots or replays to the documentation to help other developers follow along.

At Replayable we're laser focused on improving documentation and developer experience. If you need any help contributing to open-source docs, drop in our Discord and we'll help you out.

How to build your website at super-sonic speed with Astro.

Ian Jennings — Mon, 26 Sep 2022 17:46:40 +0000

Astro is a new and popular framework for building content-focused websites like blogs, portfolios, or documentation sites.

It fills a niche similiar to that of tools like Hugo, Gatsby, or 11ty, but differentiates itself with some distinct features:

Astro Islands: interactive UI components in an otherwise static page
Choice of frontend framework: Use React, Vue, Svelte, and others

Let's set it up on Windows using WSL!

This tutorial assumes you have WSL, npm, and VSCode set up.

Set up

Enter your WSL environment and run this command to initialize your Astro project's directory:

npm create astro@latest

First, you must name your project's directory. We'll use the default for this tutorial.

Then choose a template. We'll go with the recommended choice: "Just the basics".

When prompted to install dependencies, press enter to choose the default of yes.

After dependencies finish installing, press enter again to make your project a git repository.

Finally, choose how to set up TypeScript. Let's choose "Strict" as it's recommended.

Let's run the development server to see test that everything works as intended.

Change to you project's directory, then run this command:

npm run dev

Wait for the server to start and open the local address in your browser.

If you see the dev server's home page, Astro is fully set up and functional. We're now ready to build our own site.

Building your site

To demonstrate the basics behind editing our site, let's make some changes to the home page!

Navigate to the directory containing astro.index:

cd src/pages

Now open this file in the editor of your choice. Here I'm using VSCode with its WSL support.

There's a lot going on in this file. Let's replace its contents with the bare minimum:

---
---

<html lang="en">
  <head>
    <title>My Homepage</title>
  </head>
  <body>
    <h1>Welcome to my website!</h1>
  </body>
</html>

Navigate your browser to Astro's local server to see the blank canvas of your new site.

From here, the possibilities are endless, and with Astro as our guide, let's shoot for the moon!

Never miss another bug with dashcam for local dev

Ian Jennings — Mon, 19 Sep 2022 19:14:16 +0000

Capturing a 2048 bug with Replayable

How often have you encountered a bug while testing an app you’re building? How often are those bugs completely unrelated? Do you stop what you’re doing and go after them? Or just let them slide and move on?

If you stop what you’re doing to capture it, you need to remember what happened. You then need to launch a screen recorder and hope that you can reproduce the issue. If the reproduction takes multiple steps, you might waste time trying to get the application in a state for it to happen again. It’s extremely frustrating.

You might choose to save troubleshooting for later so that you don’t kill your developer flow. Who wants to stop what they’re doing to write steps to reproduce something unrelated? You know that you need to fix the bug, but it interrupts your current focus and workflow.

Why you shouldn’t interrupt a programmer

As a part of the “shift left” movement, developers now play a larger role in QA and testing. QA is no longer the responsibility of another team. It’s a combination of automation and development. Developers are responsible for finding and documenting bugs, and that competes with their ability (and love) for coding.

Once a bug is found, the developer needs to support it. It needs to be documented, then you need to tell the product team about it, and maybe there’s a meeting (or three). It’s a huge PITA. With the rise of remote work, developers can’t just grab their coworkers and say “hey, take a look at this.” Instead, they say that “it works on my machine.”

Wouldn’t it be great if you could just capture the bug when it happened in the first place? No more meetings, video capture, descriptions, reproducing steps, follow-ups, .

Trimming a clip in Replayable

That’s why we’re building Replayable. Replayable is a dashcam for developers that helps you upgrade your bug reports with clips from local development. Rather than taking the time to reproduce and explain, you can simply grab footage of bugs when they happen. It’s like a black box on an airplane. Anyone who reads the bug report won’t need to follow ambiguous instructions, ask follow-up questions, or the dreaded “what version are you on.” It’ll be in the clip.

Replayable helps you show your team what you’re talking about instead of constantly trying to explain and describe the situation. It gives your team all your information – your perspective when shit hits the fan. You get to stay focused and feel peace of mind as you know that when anything goes wrong, you’ve got footage of it – just like a dash cam.

It works just like a dashcam too. Replayable records your screen LOCALLY in the background while you work (and yes, it’s performant). Whenever you encounter a bug, just hit the hotkey or press the “create clip” button and you’ll get a video of whatever happened in the last 30 minutes.

You have a chance to trim, crop, and censor the replay before publishing. Once you publish, you’ll be presented with a quick sharing link for markdown, Jira, etc. In fact, you can even do this all in one line with the CLI. But more on that later.

Embedding a Replayable clip in GitHub

Not quick enough? The Replayable buffer records up to 3 days of footage, so you can upload Friday’s bug during the Tuesday standup. Replayable keeps its replay buffer on disk so your RAM doesn’t fill up, and it records at a low FPS, so things take up less space.

So how does it work? Imagine I’m playing 2048, and a bug pops up. Oh no! I hit the “Create Clip” button and capture it. I trim only to show me encountering the error (and the time leading up to it), then I crop and upload. I can then use the sharing dropdown to embed the replay within GitHub, Jira, or wherever your bugs go. I can go into the console.log and attach the logs to the replay as well.

In fact, you can even do most of this automatically by triggering a capture when the browser hits an error, but more on that later. For more, check out our CLI, Jira integration, and docs. Follow us on Twitter and join our beta!

How to improve the DX of your readme with embeddable demos

Ian Jennings — Wed, 14 Sep 2022 23:05:56 +0000

For the full demo, take a look at the before and after.

While your readme might make sense to you, chances are you’ve probably left out some important information that other developers would appreciate. Just think about all the readmes you’ve followed. Have you ever had one where you wish the author provided better information such as:

Shows commands, but not their output
Only a documentation reference, but no examples of usage
Broken or missing demos
Need to clone and install just to run the demos
Detailed contribution guidelines, but nothing about usage

These problems negatively impact the DX (developer experience) for devs who want to get started with your product. Every time developers get confused, encounter a bug, or have a question, it costs them time, and they’re more likely to give up using your tool.

Unsurprisingly, it’s hard to empathize with newbies who haven’t used your repository before. You already know how everything works, and it’s hard to guess what a newbie would need to know.

That’s why we made Replayable. Replayable helps developers upgrade their readmes, bug reports, and pull requests with video so other developers can understand the context behind their contributions.

Rather than jotting instructions down in text format, Replayable simply captures your screen as you work so you can easily attach video clips that contain an exact record of what actually happened.

Replayable captures all of the context, the running demos, the CLI output, usage, and how you – the creator – use the product. A demo is worth a thousand words, and Replayable transforms your everyday work into demos you can share with your audience.

Replayable vs Video Tutorials

Why video? While your code, examples, and prose may be enough to give developers an overview, videos capture your entire point of view. Rather than trying to explain your process manually (lossy), videos tell a complete story to your reader. In fact, 60% of developers report using videos to learn how to code.

Now if you’re not in that 60% you may be thinking, “I hate learning from videos!” Traditional videos for developers are long, boring, and unsearchable. Replayable allows you to create short clips to embed in readmes rather than long unbearable videos.

The unique thing about Replayable is that it makes adding video as easy as setting up your own project!

Rather than stopping what you’re doing, turning on your webcam, microphone, and trying to nail the perfect demo, Replayable keeps you in the flow by making it easy to add short clips along the way. Just hit the hotkey, trim, crop, and embed.

Not only that, but tutorials created with Replayable are easier to maintain. When they go out of date, all you need to do is update a single part rather than re-render the entire video clip.

Walkthrough

Get Replayable

Let’s get started! To start, you’ll need the Replayable desktop client.

Replayable runs in the background so you don’t need to start or stop recording while you work.

Instead, you’ll simply hit Create Clip or use the hotkey to capture whatever just happened on your screen. Replayable keeps a rolling buffer locally on your computer, which you’ll be able to review and edit before uploading.

Make a new Replayable project

Replayable projects are like folders. Every time you change repositories or local projects, you’ll probably want to make a new Replayable project as well.

Use the existing guide as a baseline

Now, it’s time to make a tutorial. Your tutorial will probably mix existing setup guides and some with your own spin. After all, a lot of development is implied. It’s our job to document every nook and cranny that a newbie might not infer.

This tutorial will work on improving the getting started guide for reveal.js, a JS framework for making presentations. We’re going to follow their install guide as a base:

## Full Setup <span class="text-gray-500 font-normal">- Recommended</span>{id="full-setup"}

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

1. Install [Node.js](https://nodejs.org/) (10.0.0 or later)
1. Clone the reveal.js repository   
    ```

shell   
    $ git clone https://github.com/hakimel/reveal.js.git


    ```
1. Move to the reveal.js folder and install dependencies   
    ```

shell   
    $ cd reveal.js && npm install


    ```

1. Serve the presentation and monitor source files for changes   
    ```

shell   
    $ npm start


    ```
1. Open <http://localhost:8000> to view your presentation

Upgrade the tutorial with replays

Using the existing readme as a guide, follow the steps yourself in a clean environment . The first step is to install Node.js. As this is not unique to this repository and is likely well documented, it can be skipped.

Looking at the readme, the first step is to clone the repo. So do that on your machine. When you’re done, hit the Replayable hotkey to create a replay.

You can then crop the terminal and relevant browser page, then click the upload button. This will publish the replay to http://replayable.io and make it ready for sharing!

Watch Downloading and Installing Reveal.js on Replayable

Readmes on GitHub are created using the markdown format. To embed your replay within your readme, select Share and Markdown from the replay page. This will copy the markdown embed code to my clipboard. The markdown code includes a looping gif and a link to the replay.

You may also choose to turn the list into paragraphs to fit the embedded replays better. After every heading, paste the markdown code right after. Check out the final setup step below and the full result here.

# Getting Started with Reveal.js

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

## Download and Install

[![Downloading and Installing Reveal.js](https://replayable-api-production.herokuapp.com/replay/630402cadf25a7006524c669/gif?shareKey=AfkCnX717yYvNbX3juCDUQ)](https://replayable.io/replay/630402cadf25a7006524c669/?share=AfkCnX717yYvNbX3juCDUQ)

Make sure you have [Node.js](https://nodejs.org/) (10.0.0 or later) installed. Then, clone the reveal.js repository:

     ```


     git clone https://github.com/hakimel/reveal.js.git


     ```

Next, move to the reveal.js folder and install dependencies:

    ```


    cd reveal.js
    npm install


    ```

Then, do it again for the demo step!

Launch the app, view the presentation, and make changes. In the replay below, I wanted to understand how to modify my slides, so I launched VS Code and edited the first slide.

This is the kind of instruction where a video can be extremely helpful. While the text may make sense to you, a newbie might make errors when running npm start. They might not understand the relationship between the browser and the terminal in regards to “localhost,” and they probably don’t know what “monitor source files for changes” means.

Watch Setting up and running the Reveal.js Demo on Replayable

Not to mention, they probably can’t infer what will pop up once the demo runs. In fact, you probably don’t even know yet! So as you get the demo running for yourself, creating clips helps explain to others what the resulting output of these instructions is and provides context for how you got there.

## Run the Demo

[![Setting up and running the Reveal.js Demo](https://replayable-api-production.herokuapp.com/replay/63040495973b2c0062e9239f/gif?shareKey=tbbKqBecjPCoLBmb0QfCXw)](https://replayable.io/replay/63040495973b2c0062e9239f/?share=tbbKqBecjPCoLBmb0QfCXw)

Serve the presentation and monitor source files for changes:

    ```


    npm start


    ```

Then, open http://localhost:8000 to view your presentation!

Any changes you make to the source files will automatically be reflected in the presentation.

Publish the Tutorial

That’s it! You’re ready to publish. If you’re contributing to a repository, now you can open pull requests. Replayable embeds are supported everywhere, GitHub, Jira, WordPress, Dev.to, and more!

If you want to try Replayable out for yourself, join our beta and come hang out with us in Discord!

Learn more about your candidates with video take-home challenges

Ian Jennings — Tue, 27 Apr 2021 19:43:01 +0000

After years of testing developer experience, today I'm turning the tables and letting you test your developer candidates!

Paircast.io is the platform we built for testing DX and it turns out it's mighty good at assessing developers' skills.

You can see how developers solve problems and where they get stuck as they complete coding challenges on their own machine. You get all the quality of a technical interview with the convenience of a take-home assignment. No engineers needed to conduct technical interviews.

👉 Learn more by watching how developers solve problems, not just end results.
👉 Real-world work, not brain teasers
👉 No more cheating on take-homes, you can see developers write every line
👉 Get a higher signal with less time invested by your candidates

Personally, I'm super excited to launch Paircast into the world as I'd never pass an online coding challenge myself. After hearing a bunch of MLH Fellowship students complain about these coding tests, I knew there had to be a better way. Let's burn "crack the coding interview" and focus on real-world skills!

5 ways developer experience (DX) is different than user experience (UX).

Ian Jennings — Thu, 04 Mar 2021 18:04:15 +0000

Why do we need developer experience?

You test your code to make sure it works. But is it usable? Do you wonder why it's so difficult for other people to use your library?

Well, chances are you're the world's leading expert in whatever it is you built. Nobody else knows it as well as you, and that gives you as warped perspective.

As the founder of Haxor Developer Experience Testing, I hear this time and time again. Some smarty pants engineer built a library, wrote a readme (which is really just a collection of their CLI commands), and thinks anyone else who can't use the product is "stupid."

I was that engineer once, but when I moved into product roles my perspective changed. As engineers, we spend a lot of time thinking about systems, but we forget about people.

What is developer experience?

This is where developer experience comes in. If you haven't heard, developer experience (or DX) is user experience for developers. It's the study of human computer interaction when the "human" is an engineer writing code.

Sometimes I think of it as human-computer-computer interaction. In the modern days of APIs, often times I'm interacting with a computer, which is sending a message to another computer.

What is the difference between developer experience and user experience?

One user experience professional I met outright got up and left when I said that DX and UX were different. They insisted they were the same, and the same rules and tools applied.

That forced me to really think about the differences. Consider the experience of someone ordering a pizza through their phone, and someone who's ordering a pizza through an API.

1. Intention

A user's goal is to order a pizza. Their task is complete when the pizza gets to their house, and they consume it.

A developer's goal is to build an application. The goal is to create, not consume.

2. Task Time

Someone ordering a pizza might complete the entire process within 10 minutes.

According to our research, it's generally going to take at least 30 minutes for a developer to make an API call and at least an hour to do anything useful.

3. Environment

Ordering a pizza happens within an app, on your phone. All of the information and tools exist within one small container. Most of the time there isn't a need to leave the soft padded confines of the app, unless something drastically goes wrong.

On the contrary, development happens on a local machine. Every developer's device is different; they have different operating systems, packages, versions, preferences. While a user might have an outdated Android, a developer is using Google Chrome or VS Code with 20 extensions created by other developers.

A developer is not restricted by the confines of a developer portal or documentation. We often find that the best developer resources are 3rd party and our clients aren't even aware of those guides. Think about how many times you've used Stack Overflow instead of some official documentation.

4. Learning

A user can learn everything they need to know about ordering a pizza within the application. They've ordered pizza before, and they've definitely eaten it. There are standards in user interface, we don't need to explain what a button or text field is.

A developer is overwhelmed with knowledge, new proprietary vocabulary, brands, tech lingo, and concepts they've never seen. It would be akin to ordering an entirely new type of cuisine.

5. Scale

Most of the time, you're ordering pizza for yourself or your family. It's easy to make decisions that only affect yourself or people close to you.

Have you ever ordered pizza for a large group of people? That's what it's like for a developer. Every decision affects some infinite number of users of their app. While you might not think much of something like a 5 second delay, it makes a big difference scaled across thousands of users.

It's still just UX for development

Despite these differences, we can still apply UX concepts. In fact, it's not as difficult as it sounds.

Our task times are longer. Our user experience testing needs to happen on the desktop. We create documentation that guides users and do everything we can to support scale.

It's a very interesting time right now. UX researching are asking "how can I get involved with DX?" and at Haxor, we're constantly talking to DX and DevRel folk about UX concepts. DX is truly the hybrid between developers and UX.

Developer Experience Testing

If you're interested in testing the DX of your API, reach out to us at Haxor. And if you're a developer who wants to shape the future of developer tools, sign up for our mailing list.

The Haxor Manifesto

Ian Jennings — Wed, 03 Mar 2021 17:07:00 +0000

My name is Ian Jennings, and I'm the founder of Haxor, a company focused on making development faster and more accessible for everyone.

If you're anything like me, you're riding the the new kingmakers wave. Programming wasn't cool when I was growing up. Mike Swift, who started MLH, didn't reveal to me that he was a coder until our Junior year at Rutgers. That all changed when "the social network" came out.

In fact, everything changed. "Hacker culture" blew up. Where "hack" was a bad word spit on major news networks, now we were reading listicles of 21 kitchen cleaning hacks. Hacker culture became mainstream.

Marketing jumped in, KPIs were formed, "developer evangelism" became "developer relations" and I started hearing members of my community say "I'll market anything" and "our plan for Q3 is to penetrate the community".

Somewhere along the way we lost sight of what we were really doing, empowering people to create their own future. Leveling the playing field.

Now we're riddled with SEO spam, undocumented computer generated SDKs, and more complexity than ever. Small startups are somehow supporting 100 different SDKS. Coding is the new literacy, and we're writing pulp fiction.

Stats from a couple of StackOverflow Developer Surveys

You'd be surprised how many SDKs, tutorials, and docs are never once tried by their authors. Never! Sure, the tests pass, but that documentation that every customer needs to read? I'll bet the author never ran it from scratch.

We rely on "the community" to report issues back to us. They file a GitHub issue, nobody looks at it, and a bot automatically closes the ticket a week later. In the end, companies get their eyeballs and developers have their time wasted. Makes sense, because marketing is the only department with analytics.

As a developer, how many times have you turned away from a product because their code samples didn't work? It's easier to git stash and try a competitor than to brute force your way through. 10 years ago, there were no competitors. Don't get me started on lock-in.

The only people who can manage to get anything done these days are "haxors". They're the developers who, despite the awful state of documentation, manage to get things done quickly.

haxor(Noun) An uber way to say hacker. Usually refers to a skilled hacker. Etymology: haxor as a leet spelling of hacker became so common an example of leetspeak that haxor became synonymous with leet in this context.

I want to make everyone a Haxor. There's no reason any two developers should encounter the same bug twice. That's why I've spent the last 2 years working on improving the accessibility of developer tools.

Developer feedback in Paircast, a developer screen recording tool we developed

How? Though I can't locate it now, I read about this amazing idea from someone in DevRel. Once a month, have some developers try your product and see where they go wrong. Like usability testing for developers. Genius. Ask the developers, who would have thought.

So that's what Haxor does; developer experience testing. We identify the ways that developer companies can make their tools more accessible. More accessibility means more signups, and when developers are the customer, that means more sales.

In the very first test we ran, we found that 5/5 developers couldn't sign up for an API. It turns out they had Adblock enabled. This is a public company on the NASDAQ. Since then, we've given away more than $15,000 in cash , gift cards, and swag to developers.

If you're a developer who wants to help make the world better for noobs, Join the Haxor Discord to learn how you can participate in our developer challenges.

And if you're a DevRel, Product Manager, or CTO who wants to know how you can remove the friction that's preventing developers from paying you, we'd love to work together. We're running a new promotion where your first feedback session is free.

Transform code screencasts into markdown tutorials for Dev and GitHub

Ian Jennings — Thu, 16 Jul 2020 13:59:47 +0000

Writing tutorials is tedious

When you write tutorials on Dev.to (or GitHub, or anywhere else) your workflow is probably repetitive. Maybe it looks something like this:

Create the full app
Break the app into code samples
Awkwardly arrange the code samples in order
Follow along yourself
Realize the code samples don't make sense
Make a ton of edits
Write explanations for each code sample
Do everything again for a video

You end up repeating your work and explaining yourself over and over; in this case, at least 3 times. If something needs to be updated, well, start all over.

That's why I created Paircast. I spent 6 years in Developer Relations writing tutorials. I dreamt of a better way, then I built it.

Screencasts as documentation

Paircast squashes all these steps into a single process.

As you work, Paircast records your screen, microphone, and camera like a screencast or live-coding on Twitch.

Now I know what you're thinking. Video sucks for coding. You can't search, you can't copy and paste, and it's hard not to navigate.

Paircast uses git behind the scenes to track file changes and align them with your screencast. Code changed are displayed as git diffs within a markdown file next to your video. See a demo here.

Publishing to Dev.to, GitHub, and more

Not only that, but Paircast transcribes your voice and weaves what you say between the code changes.

This turns your code screencast into a full-on markdown tutorial you can post to Dev.to, GitHub, or even embed in your repo readme or documentation. See an example of that output on Dev.to or GitHub.

And what about git?

Paircast actually links commits back to the video as well. So when you upload your full example to GitHub or GitLab, developers can jump to the point in the video where that line of code was created!

Check out the docs on using git blame with Paircast for more on that.

Get Started

Ready to get started!? Awesome. Paircast is available for Mac and Windows, and it works with any programming language.

Paircast is currently in beta, but you can get instant access just by joining our Discord. Stop in, say hi, talk to our #beta bot, and let me know how things go.

Beyond docs and tutorials

It doesn't stop here. I designed Paircast to be "screencasts for developers," and the use cases go far beyond tutorials. You can use Paircast for:

Documentation
Creating onboarding guides
Answering support emails
Interviewing developers with coding takehomes
Video Pull Requests
Performing code review
Conducting developer experience research

I've got a lot of writing to do! Follow Paircast here on Dev.to to follow the Paircast journey.

Paircast Demo Output

Ian Jennings — Wed, 15 Jul 2020 17:47:53 +0000

What's going on here?

Paircast generates markdown documentation from coding screencasts.

The following is an example of Paircast output. The markdown that created this post came directly from the View Source button on the homepage demo.

What are the little timestamps like ^00:13? These link back to the Paircast video at the time that markdown was generated.

Learn how you can record your own Paircast.

Demo Output

Welcome to Paircast.^00:01

Paircast helps developers automatically documet their code by aligning screencasts with code changes. ^00:04

Everything I say as well as my code changes are transcribed (into markdown) right next to my video. Just watch as I ended this Swift file. ^00:13

diff --git demo.swift demo.swift
--- demo.swift
+++ demo.swift
@@ -1,2 +1,4 @@
 // Hello, World! Program
 import Swift
+
+print("Hello, World!")

You can use a Paircast to make: ^00:17

Readmes
Tutorials
Pull Requests

Developers can copy-and-paste code out of your screencast, and they can even see the screencast within git history. ^00:22

Paircast works with any programming language, and it's available for free for Mac and Windows. You can get started at Paircast.io. ^00:36