Live-demo failures are mostly a settings problem: one speaker's Rider checklist

A dev.to post titled "My JetBrains Rider Setup for Surviving Live-Coding Demos" sets out what its author, writing as lovelacecoding, changes in the IDE before speaking at a tech event ^[1]. The useful part is the ratio: the author frames the goal as getting through a live demo without fighting their own tools on top of their nerves ^[2], and almost everything on the list is configuration you set once, days in advance, not composure you summon on stage.

Start with the display. Presentation Mode sits under View > Appearance > Enter Presentation Mode, fills the screen with the editor, and increases the font size automatically, so font size is not something you fiddle with at the lectern ^[3]. The zoom level it uses can be fixed beforehand under File > Settings (Preferences on macOS) > Appearance & Behavior > Appearance, which the author recommends precisely so the size is already right the moment the mode goes on ^[4]. Then the theme: the author switches to light, on the grounds that dark themes often look washed out under conference lighting and projectors and that light backgrounds read better from the back of the room ^[5]. That last one is a preference claim, not a measurement, but it is cheap to test on the actual projector. Three toggles, all pre-settable ^[2].

The structural change is bigger. Rather than switching between PowerPoint and Rider mid-demo, the author writes slides in Markdown and previews them inside the IDE using MARP ^[6]. The setup is a package.json next to the presentation file carrying a marp script ("marp index.md -w --html --allow-local-files") and @marp-team/marp-cli at ^4.5.0 as a devDependency ^[7], plus an index.md whose slides are separated by --- ^[8]. After npm install, Rider shows a run button next to the script, and the -w flag rebuilds the HTML on every save ^[9]. Right-clicking the generated HTML and choosing Open In > Browser > Built-in Preview puts the slides in a tab beside the code, reachable with the IDE's normal tab shortcuts ^[10]. Pressing P in the preview opens a speaker-notes window you can park on a second screen ^[11], and the --html flag allows Mermaid diagrams in slides ^[12]. For JavaScript and Vue talks the author uses Slidev instead ^[13]. Net cost: two files in one folder and one dependency install ^[1].

Navigation is the same story. Search Everywhere on a double Shift jumps to a file, class, or action by a few letters ^[14]; Recent Files is Ctrl/Cmd+E ^[15]; Recent Locations is Ctrl/Cmd+Shift+E and shows actual code snippets from places you edited, which helps when you remember the code but not the filename ^[16]. The author's stated purpose for all three is moving between the two or three files a demo actually uses ^[17], and switching from a working project to a backup project when something goes wrong ^[18]. The source text breaks off mid-sentence at that point, so the backup-project procedure is not spelled out ^[19]. Nearly all of this transfers to WebStorm, IntelliJ IDEA, PyCharm and the other JetBrains IDEs, which share the underlying platform ^[20].

Worth watching if you copy this: the author's claimed win is one less app to manage and one less thing to go wrong ^[21], but the MARP route trades a slide app for a Node toolchain, a pinned CLI version ^[7] and a watch process. That moves the pre-flight check rather than removing it, and the check now belongs on the machine you will actually present from, offline, the day before.