Skip to content

Latest commit

 

History

History
63 lines (39 loc) · 4.94 KB

rppt-week-04-pair-programming-at-glitch.md

File metadata and controls

63 lines (39 loc) · 4.94 KB
id
devto

@import "dev-to-style.less"

- Week 4 of my Remote Pair-Programming Tour -

Johnicolas invited me to pair with him after reaching out to developers in the #PairWithMe channel on the Software Crafters Slack workspace. He works in the infrastructure team at Glitch and is an enthusiastic software crafter and Test-driven development (TDD) practitioner.

Glitch is the name and a product of former Fog Creek Software, who invented Trello and co-created Stack Overflow, tools which every developer know and probably use every day. You can imagine it as a Google Docs for developers, or as JSFiddle for (also) back-end (Node.js) code. The live-editing and auto-deployment features are remarkable, and for getting started you don't even need an account for getting started. Just play around and carry-on your projects later if you like it.

Test-driven-development with Glitch

{% glitch game-of-life-kata app %}

For getting to know each other and Glitch better we decided to do a code kata as an exercise. Code katas follow the idea of delibarte practice, meaning to do a simple exercise over and over again in order to be able to pay attention to a specific technique and focus rather on the process than the actual result.

The integrated editor of Glitch doesn't have built-in support for running tests, which is why Johnicolas suggested using Intern which runs the tests in the browser and displays a nice user interface with the result. Combined with the auto-refresh on every keystroke feature of Glitch it provides a nice development experience for test-driven development. The result can be shown in a side-panel to the right, so you have immediate feedback while typing your code.

Here is a template if you want to try out testing with Intern yourself: https://glitch.com/~intern-test-template

Pair-Programming using Glitch

The Google Docs-like collaboration experience of Glitch makes it a very interesting choice for Pair-Programming as well. You can get started quickly, start from scratch, or remix an existing project.

Practicing JavaScript-based code katas is also very easy, as you don't need to set up any development environment. Just start hacking.

Pair-Programming with VSCode Live Share

For the actual task we wanted to collaborate on this week, we decided to work with VSCode. VSCode provides the Live Share feature, which works really well for remote pair-programming. Compared to other alternatives, it doesn't require to sync the whole project. Instead, it just opens the requested files from the hosts PC via SSH. The disadvantage is that it seems the code can not be accessed with external tools outside VSCode, which is probably not a problem for many projects.

Live Share also offers a Shared Terminal window for running tools (e.g. npm scripts) on the remote host in a collaborative way, and even server ports can be shared by the host. What we didn't try was co-debugging, which might be handy as well, although if you are doing TDD a debugger should rarely be necessary 😄.

Merging multiple RegEx Tests into One

One of the tasks Johnicolas was suggesting we could collaborate on was refactoring a TypeScript class called BadRexer responsible for detecting malicious patterns in the project files of Glitch users. The current architecture was to test each file for multiple RegEx patterns and suspend the project if one of the patterns was found.

The current approach was working good enough for most of the projects, but can cause some issues for bigger projects as each file has to be re-scanned for each pattern, which means in the worst case N files have to be scanned M times if the project doesn't contain any malicious pattern (which should be the normal/majority case).

Johnicolas already had an idea how this can be improved, and the idea is as elegant as simple: Merge each RegEx pattern into a single pattern by logically "or"-combining them. This of course only works if you don't need to know which test failed, which was the case in our scenario.

Some Regex Features may cause exponential worst-case runtime complexity

https://github.com/uhop/node-re2/#why-use-node-re2

Heavy clean-up of test code

Let it crash