Hardkoded

Stream Deck as an Agentic Productivity Tool

2026-09-04T00:00:00+00:00

In Getting Out of Worktree Hell I wrote about stable worktrees: a fixed set of six, wt1 through wt6, each tied to its own cmux session. Same names everywhere — terminal, Chrome tab group, piece of work.

That fixed the chaos. It did not fix the switching. When Claude is running across those workspaces and I’m in a browser reviewing a PR, jumping back still means hunting the right tab, the right session, the right place where something is waiting for me.

Not just for streamers

Elgato’s Stream Deck shows up in every streamer desk photo. Lights, scenes, mute. Fine. But a grid of programmable keys with live status is also a pretty good surface for an agentic workflow.

You are not one person at one terminal anymore. You are coordinating several agents, several worktrees, several “please pick one” prompts. A physical deck is a control panel for that — status at a glance, one tap to jump, no ⌘-Tab spelunking.

Worktrees on the deck

Gonzalo Serrano built streamdeck-cmux, and it maps straight onto the stable-worktree setup.

Each key is a cmux workspace. Background color matches the sidebar. A lighter key is the one you are on. An orange bar means it needs input. Pink means Claude is running. Progress and working directory show up on the key itself.

Press a key and you land on that workspace — the same wt1–wt6 I already use as a WIP limit, now one tap away from whatever I was reading in the browser.

Answering Claude from the keys

Claude Code asks a lot of multiple-choice questions. Leave the keyboard, find the terminal, read the options, type a number. Fine once. Annoying when six worktrees are asking at once.

So I built streamdeck-claude-answer. When Claude asks, the question lands on the deck. Top-left tells you which directory is asking. The numbered keys are the options. Press one, the answer goes back, and the deck returns to whatever profile you were on.

No network daemon. Claude writes a question file, the plugin watches it, you press a key, an answer file goes back. That is the whole loop.

Will it stick?

I don’t know how well this will integrate into my daily workflow. Buttons are fun for a week and then they collect dust. But the problem is real — too many agents, too many waiting prompts — and a deck that shows status and takes answers feels worth trying.

I’ll give it a shot.

Don’t stop coding!

The state of unit testing in the AI era

2026-08-14T00:00:00+00:00

The title of this post looks like deep research of unit testing and AI, but it’s more a set of random thoughts.

Unit testing used to be an important part of our code review. That was the first thing I would look at on a PR. Tests were supposed to show the reviewer how the code works, and then you would go to the implementation.

Remember TDD?

We also fought for test coverage. “Hey, this line doesn’t have coverage?”

Now we take unit tests and test coverage for granted. The AI will make sure there is a unit test for every single line of code.

And the main problem is that those tests are what I call self-reinforcement tests. The AI validates what the AI did, not what the AI was supposed to do.

And it creates lots of tests. LOTS.

I was talking with a colleague about this a few days ago and I found something pretty sad. We ended up just marking the test files as “viewed” in GitHub.

What used to be the entry point for reviewing is now noise.

I created some skills and rules to fight that. The one that stuck: split the tests.

Spec tests describe what a feature does. A handful per file. They read like documentation. Those are the ones you open first on a PR.

Unit tests pin down individual functions and edge cases. As many as you need. They can live in a different file so they don’t bury the story.

Same runner, same CI. The split is for humans.

It helps. A bit. You can find the tests that still mean something.

But it looks like we need to make an effort to go back and give unit tests the place they deserve.

Or is it that we don’t need them anymore?

But there are two things I will never skip. E2E tests for the UI. And it might sound old-fashioned, but I will ALWAYS do a manual test on user-facing features.

This sits next to how I work with agents day to day: getting out of worktree hell and pr-memory.

Final words

I don’t have a clean answer. I know I don’t want to mark 40 test files as viewed and call it a review. If the tests don’t tell me what the code is supposed to do, they’re just the AI talking to itself.

Don’t stop coding!

New .NET Library in Town. Let's Welcome ReactiveExtensions-Sharp

2026-08-09T00:00:00+00:00

Puppeteer-Sharp has one simple goal: to be a port of Puppeteer, as close as possible.

Close in the API. Close in the .NET flavor, because a C# developer should feel at home. But also, and this is the part nobody sees, close in the internals. When the internals match, porting an upstream fix is a mechanical job instead of a research project.

And that’s where things get interesting, because Puppeteer uses rxjs.

The rxjs inside Puppeteer

Some of it is small and lovely. This is Puppeteer waiting for the fonts to be ready before printing a PDF:

await firstValueFrom(
  from(
    this.mainFrame()
      .isolatedRealm()
      .evaluate(() => {
        return document.fonts.ready;
      }),
  ).pipe(raceWith(timeout(ms))),
);

Read it once more. “Take this promise, turn it into a stream, and race it against a timer.” One expression. No token source, no Task.WhenAny, no cleanup.

And then there is stuff like this, which is how the BiDi implementation waits for a navigation:

return await firstValueFrom(
  combineLatest([
    race(
      fromEmitterEvent(this.browsingContext, 'navigation'),
      fromEmitterEvent(this.browsingContext, 'historyUpdated').pipe(
        map(() => {
          return null;
        }),
      ),
    )
      .pipe(first())
      .pipe(
        switchMap(navigation => {
          if (navigation === null) {
            return of(null);
          }
          return this.#waitForLoad$(options).pipe(
            delayWhen(() => {
              if (frames.length === 0) {
                return of(undefined);
              }
              return combineLatest(frames);
            }),
            raceWith(
              fromEmitterEvent(navigation, 'fragment'),
              fromEmitterEvent(navigation, 'failed'),
              fromEmitterEvent(navigation, 'aborted'),
            ),
            switchMap(() => {
              if (navigation.request) {
                function requestFinished$(
                  request: Request,
                ): Observable<Navigation | null> {
                  if (navigation === null) {
                    return of(null);
                  }
                  if (request.response || request.error) {
                    return of(navigation);
                  }
                  if (request.redirect) {
                    return requestFinished$(request.redirect);
                  }
                  return fromEmitterEvent(request, 'success')
                    .pipe(
                      raceWith(fromEmitterEvent(request, 'error')),
                      raceWith(fromEmitterEvent(request, 'redirect')),
                    )
                    .pipe(
                      switchMap(() => {
                        return requestFinished$(request);
                      }),
                    );
                }
                return requestFinished$(navigation.request);
              }
              return of(navigation);
            }),
          );
        }),
      ),
    this.#waitForNetworkIdle$(options),
  ]).pipe(
    map(([navigation]) => {
      // ...
    }),
    raceWith(
      timeout(ms),
      fromAbortSignal(signal),
      this.#detached$().pipe(
        map(() => {
          throw new TargetCloseError('Frame detached.');
        }),
      ),
    ),
  ),
);

I won’t pretend I understood that on the first read. Or the second. But once you do, it says exactly what a navigation is: race a navigation event against a history update, wait for the load, wait for the child frames, wait for the request chain to settle, and race the whole thing against a timeout, an abort signal, and the frame being detached.

Every “and also this can happen” is one more line, not one more branch.

Doing that in plain C# is not impossible

It’s just very hard to keep up with.

Puppeteer-Sharp’s Locator retry loop is a while (true) with five catch clauses, one of them holding a try inside a catch, plus a comment explaining that try inside the catch, because otherwise nobody would believe it was on purpose. WaitForNetworkIdleAsync is the same story with different pieces: a System.Timers.Timer, four event handlers, a Cleanup() local function called from three different places, and a TaskCompletionSource to tie it all together.

That code works. I’m not ashamed of it. But it is bespoke, and that’s the real cost. When upstream changes one line of an rxjs pipeline, I can’t just port that line. I have to read the new semantics and figure out where they land inside my own imperative version. That’s not porting. That’s re-deriving, every single time.

“But .NET already has Rx”

I know what you might be thinking, and it’s true. .NET has Rx.NET. It’s mature, it’s first class, and it was there before rxjs.

But Rx.NET and rxjs are not the same library with different syntax. They are two implementations of the same idea that evolved separately for more than a decade. map is Select. filter is Where. raceWith is sort of Amb. “Retry with a delay between attempts” is not one call. And where the names do match, the defaults sometimes don’t.

So porting an rxjs pipeline to Rx.NET is a translation, operator by operator, hoping every edge case lines up.

I didn’t want a translation. I wanted the same code.

So now we have ReactiveExtensions-Sharp

ReactiveExtensions-Sharp is a port of RxJS to .NET. Not “another Rx library”. A port. Same operator names, same semantics, same edge cases, checked test by test against RxJS’s own spec suite at tag 7.8.2.

Which means WaitForNetworkIdleAsync now looks like this:

var idleReached = _inFlightRequestCount.AsObservable()
    .Map(count => count <= concurrency)
    .DistinctUntilChanged()
    .SwitchMap(idle => idle ? Observable.Timer(TimeSpan.FromMilliseconds(idleTime)) : Observable.Never<long>())
    .Map(_ => Unit.Default);

await idleReached
    .RaceWith(CloseSignal<Unit>())
    .RaceWithSignalAndTimer(TimeSpan.FromMilliseconds(timeout), cancellationToken)
    .ConfigureAwait(false);

That’s the whole method. The timer is gone. The four event handlers are gone. Cleanup() is gone, because unsubscribing is the cleanup.

And those five catch clauses in the locator become this:

return await Observable
    .Defer(() => Observable.From(operation(linkedToken)))
    .RetryAndRaceWithSignalAndTimer(
        TimeSpan.FromMilliseconds(Timeout),
        causeFactory: null,
        retryDelay: TimeSpan.FromMilliseconds(RetryDelay),
        cancellationToken)
    .ConfigureAwait(false);

RetryAndRaceWithSignalAndTimer is not something I invented. It’s the C# name for the combinator Puppeteer defines for itself in locators.ts: pipe(retry({delay}), raceWith(fromAbortSignal(...), timeout(...))). Same three operators, same order, same behavior.

There is an open PR doing this across Locator, WaitForNetworkIdle, WaitForRequest, WaitForResponse, WaitForFrame and WaitForTarget. 232 lines added, 502 lines deleted.

What’s in the box

100+ operators and creation functions. The whole RxJS 7.8.2 surface, not a curated subset. groupBy, expand, partition, using, bindCallback, the full window*/buffer* families, share/shareReplay with the complete reset config.
800+ tests, ported from RxJS’s own spec files. Not written from the docs. The same cases RxJS uses to check itself.
A VirtualTimeScheduler and a marble-style TestScheduler, so you can assert that a debounce or a retry-with-backoff behaves correctly across virtual time, without waiting a single real millisecond.
netstandard2.0, net8.0 and net10.0.
On NuGet as ReactiveExtensionsSharp, with API docs.

But now we have agents

This project sat on my “someday” list for years. Porting a full operator surface, test by test, is a lot of typing and not much thinking, and I’m one person with a day job.

And that turned out to be exactly the shape of work agents are good at. “Port this one operator, verify it against this one upstream spec file” is small, self-contained, and independently checkable. So most milestones ran as several agent sessions at the same time, each one in its own git worktree, each one landing its own branch.

Was it magic? . . . . No.

The most interesting bug in this repo is about disposal. RxJS has a specific trick that makes “stop listening” cascade all the way up a chain of operators. The obvious C# translation works fine for async sources and silently fails for synchronous ones, because the whole emission loop finishes before Subscribe() even returns, so the “stop” signal arrives too late to attach anywhere.

That bug was found five separate times, by five sessions that knew nothing about each other, each one patching its own operator.

Five independent rediscoveries is not five mistakes. It’s a sign the problem is structural. It only got fixed properly, once, at the architecture level, when somebody looked at all five reports together.

Later, an audit compared every ported test file against its real upstream spec. I expected it to find thin coverage. It found four genuine bugs, all of them while writing the missing tests: concat and merge had that same synchronous disposal bug in a corner nobody had checked, combineLatest completed too early when a source finished without ever emitting, concatMap could start the next inner observable before the previous cleanup had finished, and takeUntil had no error handler on its notifier at all, so an errored notifier took the whole process down.

Agents wrote most of the code. The bugs were found by reading, comparing and asking questions. That part is still ours.

Final words

You probably noticed I keep saying “we”. That’s not a writing tic. Everything I do is community based. ReactiveExtensions-Sharp is not mine. It’s ours.

It’s at 0.3.0. It’s young. The surface is complete, but the mileage is low, and low mileage is exactly what bug reports are for.

So bring new ideas, send PRs, fork it, break it! 😉

Don’t stop coding!

Claude Helped Me Be Lazy, Again

2026-07-31T21:33:03+00:00

I found out that my GitHub profile was quite old. And broken. Some links didn’t work anymore, and some things were just there because I put them there years ago and then forgot about them.

So I did what we do now: I asked Claude to update it.

It found a few things to fix, and then it said something like: “Hey, you have a list of your blog posts here and they are very old. Do you want me to update them?”

Yeah, sure. Why not?

Then I saw it fetching gautamkrishnar’s GitHub profile.

Ok, this is wrong.

It turns out it wasn’t wrong at all. Gautam Krishna built blog-post-workflow, a GitHub Action that reads your blog feed and keeps the posts in your README updated.

I never would have taken the time to look for a tool to do that for me. Not because it is hard, but because it is one of those small things that are always nice to have and never important enough to spend time on.

Claude didn’t just update my profile. It found the automation I was too lazy to look for.

Now my profile can keep itself updated when I publish something here.

Claude helped my laziness, one more time.

Don’t stop coding!

Getting Out of Worktree Hell

2026-07-20T00:00:00+00:00

Git worktrees aren’t new. They shipped in Git 2.5, back in July 2015. And for years, almost nobody used them. Checking out a second branch into a second folder was a nice trick for the rare case, not something you reached for every day.

Then AI coding agents showed up, and worktrees became the obvious answer to a new question: how do you run more than one agent on the same repo at the same time? You can’t have two agents fighting over the same branch and the same files. Give each one its own worktree, and they stop stepping on each other.

Claude Code leans into this hard. Ask it to start a task and it will happily create a worktree for you, attach it to a branch, and clean it up once that branch is gone. It’s smooth. It’s also how you end up in worktree hell.

How you end up here

One worktree per task sounds great, until you have a dozen of them open. Each one is a PR in some state: waiting on CI, waiting on review, waiting on you to remember what you were even doing in there. I built pr-memory to fix the “wait, what was I doing” half of that problem. But it doesn’t fix the other half: too many folders, too many terminals, too much to hold in your head at once.

And then, one day, you get a “disk full” alert on a machine that should have plenty of space. You dig in, and it turns out half your disk is dead worktrees: branches that merged weeks ago, folders nobody removed, build output sitting there because Claude Code created the worktree but nothing ever told it to clean up after the PR closed.

It depends on the repo

None of this is a problem on a small, single-repo project. puppeteer-sharp is one repo with a light build; worktrees come and go and you’d never notice. But once you’re working across several related repos, or a big repo with a heavy build — an Electron app, say, where every checkout drags a chunky node_modules and a pile of build artifacts behind it — an unmanaged stack of worktrees turns from an annoyance into a real problem, on disk and in your head.

Stable worktrees

For my “enterprise” work, I stopped letting worktrees multiply and switched to what I call stable worktrees: a fixed set that’s always there, reused instead of recreated.

I keep six of them, wt1 through wt6, each one tied to its own cmux session, and each cmux session living in its own Chrome tab group with the matching name. Same six names everywhere, so I always know which terminal, which browser tabs, and which piece of work go together.

There’s also a seventh, wt0. It isn’t a real worktree — it’s just a cmux tab for the stuff that doesn’t belong to any single task: loops, PR checks, crons, the background chores that don’t need a workspace of their own.

The limit is the point

Six sounds restrictive, and it is. That’s what makes it work. When all six are busy, I can’t just spin up a seventh — I have to finish something, ship it, or park it, before I start anything new. It turns the worktrees into a kanban board with a hard WIP limit, and it’s done more for shipping than any productivity tip I’ve tried: fewer half-finished branches, more PRs actually landing.

The other mess those agents create — a wall of tests nobody reads — is a different post.

Don’t stop coding!

Meet pr-memory, a Way to Put a Claude Code Session on Hold

2026-07-13T00:00:00+00:00

If you work on more than one thing at a time with Claude Code, you know the problem. You’ve got a worktree for one feature, a terminal for a bug fix, another tab for a PR that’s waiting on review. Each session has built up real context — what was tried, what failed, why a decision was made — and none of that is written down anywhere. It only exists in that one running session.

Claude Code already lets you name a session and resume it later, but in practice that’s tedious. You have to remember the name, remember which terminal, remember which of the five things you were juggling that session belongs to. When you’re deep in several worktrees at once, it’s easy to just lose track.

What I actually wanted was simpler: work on a PR, step away from it, and free up the terminal for something else — without losing everything that session knew.

So I built the pr-memory skill.

What it is

pr-memory keys session memory off the thing you actually care about: the pull request.

pr-memory save — snapshots the current session as a handoff-style document: the worktree, the branch in every repo you touched, and every related PR across repos.
pr-memory load <pr> — finds that document by any of those PR numbers and re-hydrates the session from it.
pr-memory list — see everything you’ve got saved.
pr-memory gc — prune memories whose PRs have all merged (this also runs automatically in the background).

Say you’re working on myrepo#5. You need the terminal for something more urgent, but you’re not done with #5 yet. Instead of leaving the session running or trying to remember a session name, you just say:

“Save this session”

and pr-memory writes a handoff doc — what was built, current state, open items, key learnings — indexed by #5. The terminal is now free.

Later, review feedback comes in, or you just want to pick it back up:

“Load pr-memory for #5”

and the session comes back: same context, same open items, with an offer to check out the saved branch if you’re not already on it.

It started as a personal skill tied to one multi-repo workspace I use at work, but I generalized it to work standalone with zero config in a plain single-repo checkout, while still scaling up to a multi-repo workspace if you have one.

Final Words

It’s a small thing, but it’s already changed how I juggle multiple PRs — I stop hoarding terminal tabs “just in case” and just trust that save / load will bring the context back when I need it.

It’s part of the hardkoded-skills plugin, open source as always. Give it a try and let me know what breaks.

Don’t stop coding!

Meet Cronito, a Friendlier Cron for Claude Code

2026-07-07T00:00:00+00:00

Everybody is talking about loops these days. Loop this, loop that, wrap your agent in a while and let it check on things every few minutes. And sure, that works — until you close the laptop, or the session times out, or you just forget the terminal tab was even open. Your loop needed a live session to stay alive, and the moment that session is gone, so is your loop.

I hit this constantly with Claude Code: check on a PR every few minutes, run a nightly cleanup, poll a flaky pipeline until it turns green. None of that should depend on me keeping a terminal open. What I actually wanted was a real, boring, system-level scheduler — the kind that keeps running whether or not I’m looking at it.

So, cron. Except raw crontab -e doesn’t tell you what ran, when it last ran, or why it failed. You end up with five undocumented lines nobody remembers writing, including you, three weeks later. And when the thing you’re scheduling involves Claude Code itself, there’s an extra headache: cron and launchd run outside your logged-in session, so anything that assumes you’re “logged in” quietly breaks, and now you’re debugging authentication instead of your actual task.

So I built cronito.

What it is

One unified, friendly interface for scheduled tasks, backed by a single system cron entry.

Instead of hand-editing crontab syntax, you get:

cronito add — create a task interactively: name, command, working directory, schedule
cronito list — see everything at a glance, with status
cronito edit / cronito remove — change or delete a task by id
cronito enable / cronito disable — toggle a task without deleting it
cronito logs — execution history, so you actually know what happened
cronito status / cronito dashboard / cronito health — a real picture of your scheduler, not a guess

It ships as a single dependency-free bundle, so a global npm install -g cronito (or running the bundle directly) is all it takes. One system cron entry drives everything; cronito routes to the right task under the hood.

A quick example:

$ cronito add
? Task name: nightly-cleanup
? Command: ./scripts/cleanup.sh
? Working directory: ~/projects/myapp
? Schedule (cron syntax): 0 3 * * *
✔ Task "nightly-cleanup" added

$ cronito list
ID  NAME              SCHEDULE     STATUS   LAST RUN
1   nightly-cleanup   0 3 * * *    enabled  —

But I mostly use it from inside Claude Code

Here’s the part I actually wanted: I don’t want to leave my Claude Code session just to schedule something. So I also built a cronito skill for Claude Code.

It vendors the same dependency-free bundle, so there’s no separate install step — the skill just works. Inside a session, you can type /cronito, or ask in plain language:

“Check on this deploy every 5 minutes until it’s done”

“Schedule a task that runs my test suite every morning at 8am”

“List my scheduled tasks”

and Claude drives cronito directly — same add / list / edit / logs / dashboard commands, just without you touching a terminal.

Final Words

Both repos are open source, and I’d genuinely like feedback if you try them:

cronito — the CLI
cronito skill — the Claude Code plugin

If you’ve been duct-taping cron jobs together too, give it a try and let me know what breaks.

Don’t stop coding!

Back to Sharing in a Post-Blog Era

2026-07-03T00:00:00+00:00

The last time I shared something on this blog was in 2023. Almost three years!! No, I didn’t retire (yet). I was just working. A lot.

Let’s be honest: blogs are dead. I don’t read blogs anymore either. All the good content today lives in X posts, LinkedIn articles, and, well, in a chat with Claude.

So coming back to writing here is hard. You lose the exercise, and once you lose it, sitting down to write again feels like starting from zero. But here I am, back in this post-blog era. And, not by coincidence, in the middle of an AI era too.

I use AI pretty much all the time now, and I’m not the only one. A lot of folks are doing the same thing, and sharing it.

I want to share things that actually help the community, not just chase engagement.

That’s what I’ve been trying to do for the last 8 years, and the format changing doesn’t change that.

A few things already in motion:

Puppeteer-Sharp is now fully automated with AI. You’ll hear more about that soon.
A fully native Playwright-Sharp version, coded end-to-end with AI, is coming.
Soon I’ll start sharing some of the AI skills I use every day.

As a first example: if you’re reading this post on X or LinkedIn, it got there through one of those skills, promote-post.

I hope you can get more of my posts soon :)
Don’t stop coding!

Puppeteer-Sharp 2023 Recap

2023-12-31T00:00:00+00:00

It has been a while since I wrote those Puppeteer-Sharp blog posts (maybe it’s time to do it again?). However, I thought it would be nice to recap all the progress made in 2023.

It can be quite challenging to keep Puppeteer-Sharp up-to-date. On one side I was implementing great features at mabl, that took most of my time. Additionally, I love using playwright! In my opinion, mabl is the leading low-code testing platform in the market, while playwright is the best end-to-end testing library.

So, how about Puppeteer-Sharp?

I hope that Puppeteer-Sharp can become the best multi-purpose browser automation library, the most complete CDP API in .net, and maybe, why not? the best/first Webdriver BiDi library for .net?

In 2023, Puppeteer-Sharp achieved over 9 million downloads and received sponsorship from the .NET on AWS Open Source Software Fund. These two acknowledgments were fuel for me.

My main goal in 2023 was to close the gap with puppeteer. I was able to launch 19 versions! I didn’t expect that number to be that big!
Let me share with you two of the best features shipped this year.

Query handlers

You can query elements by text:

await Page.SetContentAsync("<section>test</section>");
var testEl - await Page.QuerySelectorAsync("text/test");

Or even by Aria roles:

await Page.WaitForSelectorAsync("aria/[role=\"button\"]");

Event XPaths are also implemented using a query handler:

var els = await Page.QuerySelectorAllAsync("xpath///img");

Chrome for testing

How we download browsers also had a significant change. You can now download Chrome for testing instead of chromium. Keeping the browser up-to-date became a high-priority task.

You can look at many other new features on the release page.

About 2024.

Closing the feature gap will still be my top priority. But, the rumors about puppeteer moving to WebDriver Bidi sounds… exciting. Making Puppeteer-Sharp a great WebDriver BiDi API sounds promising.
On the personal side, I think this website need some refresh :)

Final words

What are you expecting from Puppeteer-Sharp in 2024? Should I write more? Should I share more examples? Let me know.

And remember, Puppeteer-Sharp is a library BY the community FOR the community. We build this library together. The issues tab in GitHub is open for all of you to share your ideas and thoughts. You can also sponsor the project. Even a single dollar would help me know you care about this project.

Remember to follow me on X @hardkoded for more updates.

Don’t stop coding!

What's new in Puppeteer-Sharp - April 2022

2022-04-18T00:00:00+00:00

I know, I know, I should be writing these posts more frequently, but I’m having so much fun at my new gig, and it’s not easy to keep up the pace.
It’s hard to believe it’s been a year! since my last blog post, but here we are in Puppeteer-Sharp 7!
Let me walk you through all the new features released since my last blog post.

Chromium 100

The good news is that we now support Chrome/Chromium 100! But maybe not that good news is that Chromium 100 is now the minimum requirement due to many changes in how Chromium sends requests and responses data.

Keeping the fox alive

We’ve been doing some work so you can use most puppeteer features with the latest Firefox version.

Page.WaitForNetworkIdleAsync

You now can wait for the network idle at any time using Page.WaitForNetworkIdleAsync.

Page.EmulateIdleStateAsync

You can not only wait for network idle but emulate this state! For instance:

await page.EmulateIdleStateAsync(new EmulateIdleOverrides() {IsUserActive = true, IsScreenUnlocked = false});

Drag and Drop support

Emulating drag and drop was quite hard to accomplish in the past. Now you have an API for that!

await Page.SetDragInterceptionAsync(true);
var draggable = await Page.QuerySelectorAsync("#drag");
var dropzone = await Page.QuerySelectorAsync("#drop");
await draggable.DragAndDropAsync(dropzone);

Page.EmulateVisionDeficiencyAsync

Now you can emulate different vision deficiencies using Page.EmulateVisionDeficiencyAsync.

Page.EmulateCPUThrottlingAsync

You can also emulate CPU throttling with Page.EmulateCPUThrottlingAsync!

await Page.EmulateCPUThrottlingAsync(100);

It’s our Puppeteer-Sharp!

Just a friendly reminder. Puppeteer-Sharp is an independent community project. It’s not being backed nor supported but any big (or small) corp. It depends on your support and contributions!
I want to thank Alex Maitland, Fernando Bracamonte, MantasVa, thomaschanneladvisor, Venkatesh Prasad, Matěj Štágl, jpeirson, Eric Mutta, Chris-Dev-GH, Kabue Charles, Kevin Lee Garner, Pierre Irrmann, Arnaud Maichac and brnbs for contributing to the project during this past year.

I hope you can get more of my posts soon :)

Don’t stop coding!

Puppeteer-Sharp 3 is here!

2021-03-22T00:00:00+00:00

I’m so excited to announce that, after eight months, Puppeteer-Sharp 3 is here!

Getting Puppeteer-Sharp 3 out was quite a challenge. The lack of sponsors on Puppeteer-Sharp and the strong support of Microsoft on Playwright-Sharp made me put all my efforts on Playwright-Sharp in the past few months.

But while a was writing the UI Testing with Puppeteer book, Puppeteer-Sharp got to 1 Million downloads (1 million downloads and only three sponsors), I said to myself: “Hey, let’s do something to celebrate!” So I decided to wrap up Experimental Firefox Support. And that took us to v3!

What’s new

PuppeteerSharp 3 is the first version that doesn’t fully map the same version (Puppeteer 3) upstream. It’s quite a Frankenstein, version-wise, but for good!
The first neat feature is that Puppeteer-Sharp is shipping Chromium 90.0.4403.0, which is the version that Puppeteer v8 is using.
The second new feature is EmulateNetworkConditionsAsync, which was also a feature introduced in Puppeteer v8. This method allows the use to emulate networks such as 3G or 4G.
And last, but not least: Experimental Firefox support.
You can find the complete changelog on the release page.

The state of the Fox

Using PuppeteerSharp with Firefox is as easy as passing Product.Firefox to both the BrowserFetcher constructor, and the LaunchAsync method:

await new BrowserFetcher(Product.Firefox).DownloadAsync();
using var browser = await Puppeteer.LaunchAsync(new LaunchOptions 
{ 
    Headless = false, 
    Product = Product.Firefox 
});
using var page = await browser.NewPageAsync();
await page.GoToAsync("https://www.google.com");
await page.ScreenshotAsync("./google.png");

But remember, this is still experimental. Only 340 tests of the 681 are running on Firefox. It’s not a lot, but it’s something.
I also had to turn off the tests on Windows because of many zombie processes that remained open. I found this also happens on the node version.

I want to thank Robin Richtsfeld who implemented the emulate network conditions feature, among many other things, and Simon Cropp who takes every project he touches to the next level.

What’s next

I created the V9 Project, so we can take PuppeteerSharp to what I guess will be the next Puppeteer version.

But it will be hard to accomplish it without help. I hope I can get more support from contributors on this next project.

If you are reading this post and making money with Puppeteer-Sharp, I encourage you to sponsor this project.

I hope we can catch Puppeteer soon and keep this project moving.

Don’t stop coding!

UI testing with Puppeteer book officially released!

2021-03-12T00:00:00+00:00

I’m so thrilled to announce that my book UI testing with Puppeteer has been published!
You can find it on Amazon.com and PacktPub.com. You will find all the details on the book website. Special Thanks to Facundo Giuliani for helping me set up a Jamstack website in a few hours.

Why writing a book?

When Kaustubh Manglurkar from PacktPub reached me out asking me if I wanted to write a book, I didn’t know what to say. I wasn’t (and I don’t consider myself) a writer. But Kaustubh told me something that turned my doubts into an absolute yes. He told me that there was no book about Puppeteer in the market. That put extra pressure on the project. If I was going to write the first book about Puppeteer, it should cover most of the Puppeteer API.

I can make a connection with TV shows like House or Grey’s Anatomy, where every chapter has its own plot, but there is an underlying story going on. The same happens with this book. Each chapter covers a topic, but the underlying story is the Puppeteer API.

What you will find in the book

This book will help you get started not only with Puppeteer but also with UI testing. Each chapter begins with the basic concepts before getting into the code. You will learn about automated testing in general. You will learn what test runners are and what you should expect from them.

In Chapter 4, where you will learn to interact with the page, but you will also learn about CSS selectors and XPath. You will even see a little bit about JavaScript closures in Chapter 7. Chapter 8 is about environments emulation, but I open the chapter talking about the internet ecosystem.

This book is also for web developers!!
In chapter 2, I talk about how web developers can use web automation as part of their workflow to test their UI components. In Chapter 7, We see how to generate content with Puppeteer. Then in chapter 9, I talk about web scraping and scraping ethics. The last chapter is about performance, which is something we should all care about.

Filling your toolbox

This book will give you more than a complete picture of API and UI testing. Many chapters include a bonus track, where you will learn about a tool that will be helpful in your automation journey. These are the tools you will see in this book:

Github Actions.
VS Code debugging tools.
Checkly.
Checkly’s headless recorder.
Google Lighthouse.
Puppeteer-Cluster.

Special thanks

It would be impossible to mention all the people involved in this project. I would miss many for sure. But I want to thank all the PacktPub crew, in special Kaustubh Manglurkar, for making all this possible and my editor Sofi Rogers who basically taught me to write, not just a book, to write :). You are the best Sofi!
The job of the technical reviewers was impressive! David Rubio Vidal and Jim Munro took the book to the next level.
Last but not least, thanks to my family and friends who supported me all these months. I love you all.

Final words

Maybe you are wondering, “but Dario, how about .NET? How about Playwright? weren’t you working on Playwright?’” Well, if you are interested on seeing this book on .NET or Playwright, don’t hesitate to send an email to PacktPub!

One final and personal thought. One thing I learned in this process is that writing a book is hard!!, really hard. It’s easy to be mean on social media for many of us when we don’t like something, and sometimes we forget to be thankful, even if we paid for the book we read. To all tech authors around: thank you for your hard work!

Playwright Sharp Monthly Report - December 2020

2020-12-04T00:00:00+00:00

Wait, What happened with the November report? Well, well, November was a fun month. But here we are in the December report. Let’s get started!

Important Notice.

As you might know, Playwright sharp is now part of the Microsoft family. So you should read these reports as unofficial reports. I will share here, what I was working on, what cool stuff I learned, and how I’m going to contribute to the project in the next month. I will use that line that we see quite often in Twitter bios: Opinions are my own.

Too much talk. Let’s got to the fun part.

What’s new

Since the last report, we got three new versions: v0.151.0, v0.152.0, and v0.162.0. If you read my previous report, you will know that those versions map Playwright’s versions v1.5.1, v1.5.2, and 1.6.2, respectively.

PlaywrightSharp now offers some pretty cool new features, such as Video Screencasts, HAR recording, WebSockets inspection and Tap support on mobile emulation.
Do you want to take a look at these new features? Comment this post with the feature you’d like to see, and I’ll create a post just for you, well, for everybody.

Driver and browser install refactor

PlaywrightSharp has two big dependencies: The playwright driver, a bundled Node.JS app with all the playwright logic, and the browsers used to perform the automation.
We have one driver for each platform: OSX, Linux, Win64, and Win32. And we have three browsers: Chromium, Firefox, and WebKit, which are also platform-specific.

The first approach

The first approach was to embed the drivers inside the PlaywrightSharp.dll. When you call Playwright.CreateAsync. We would extract the driver for your platform and copy it to your working directory. Then you would need to call Playwright.InstallAsync to install the browsers if required.

This approach had a few downsides.
First, We were shipping a 60mb DLL file. We could say: “ok, but we need those drivers”. But you needed only the driver for your platform, not all the drivers. This approach also prevented us from shipping platform-specific libraries, e.g., for .NET 5.
Second, we were writing files in runtime. That’s not ideal. We have the risk of not being able to write to disk in some scenarios.
Last, we were doing install tasks in runtime. If you were using it in production, Playwright.InstallAsync would cause the first call to your app to take a few minutes to download all the required browsers. Not ideal at all.

We tried to remove the need for the InstallAsync task with a dotnet tool. It did the work, but the potential problem there was that the dotnet tool was downloading the browsers for the version referenced in the tool, which might not be the same as the version your app needed.

There should be a better way.

A new approach

v0.162.0 now relies on two features:

Nuget runtimes folder.
Custom Build targets.

Nuget has something called architecture-specific folders.

If you have architecture-specific assemblies, that is, separate assemblies that target ARM, x86, and x64, you must place them in a folder named runtimes within sub-folders named {platform}-{architecture}\lib{framework} or {platform}-{architecture}\native.

So now, instead of embedding the drivers into the DLL, we are shipping the drivers inside the runtimes folder:

\runtimes 
    \osx
        \native 
    \unix
        \native 
    \win-x64
        \native 
    \win-x86
        \native 

Nuget will add a build task to copy those files depending on the RuntimeIdentifier or on the runtime used on dotnet publish.
If you don’t have a RuntimeIdentifer and don’t use the publish command (this would be a typical unit test scenario), all the drivers will be copied under a runtimes folder. That’s why if we find the playwright-cli in the current directory, we use it; if not, we try to go to the runtimes folder, looking for a platform-specific driver.

That gives us a PlaywrightSharp.dll file of only 500kb, which would allow us to ship multi-target binaries, e.g., for .NET 5. And we also removed the need for writing files at runtime.

I also learn that you can add targets inside Nuget packages. That means that you can inject your own tasks into the build process.

I created two targets that will run as part of your build process. The first task will run playwright-cli install command, installing the required browsers. At build time 😯.

 <Target Name="InstallBrowsers" AfterTargets="CopyFilesToOutputDirectory">
     <Message Text="Playwright is checking browser dependencies">
     </Message>
     <Exec Condition="$([MSBuild]::IsOSPlatform('Linux'))" WorkingDirectory="$(MSBuildThisFileDirectory)..\..\runtimes\unix$(NativeFolder)" Command="./playwright-cli install" />
     <Exec Condition="$([MSBuild]::IsOSPlatform('OSX'))" WorkingDirectory="$(MSBuildThisFileDirectory)..\..\runtimes\osx$(NativeFolder)" Command="./playwright-cli install" />
     <Exec Condition="'$(PlatformTarget)' != 'x86' AND $([MSBuild]::IsOSPlatform('Windows'))" WorkingDirectory="$(MSBuildThisFileDirectory)\..\..\runtimes\win-x64$(NativeFolder)" Command="playwright-cli.exe install" />
     <Exec Condition="'$(PlatformTarget)' == 'x86' AND $([MSBuild]::IsOSPlatform('Windows'))" WorkingDirectory="$(MSBuildThisFileDirectory)\..\..\runtimes\win-x89$(NativeFolder)" Command="playwright-cli.exe install" />
 </Target>

The second target is relatively new. It will copy the drivers if you try to use Playwright inside a Xamarin.Mac application.

 <Target Name="CopyPlaywrightDriversToMonoBundle" AfterTargets="CopyFilesToOutputDirectory" Condition="$(TargetFrameworkIdentifier) == 'Xamarin.Mac'">
     <Message Text="Copy drivers to MonoBundle" />
     <CreateItem Include="$(MSBuildThisFileDirectory)\..\..\runtimes\osx\native\*.*">
         <Output TaskParameter="Include" ItemName="PlaywrightDriverFiles" />
     </CreateItem>
     <Message Text="$(AppBundleDir)" />
     <Message Text="@(PlaywrightDriverFiles)" />
     <Copy SourceFiles="@(PlaywrightDriverFiles)" DestinationFolder="$(AppBundleDir)/Contents/MonoBundle/" />
 </Target>

Shipping process

With these changes, we wouldn’t need to call InstallAsync anymore.
If you are using PlaywrightSharp for testing, you are getting the browsers at build time.
If you are using PlaywrightSharp in Docker and you use any official Docker image, you will get the browser for free .
If you are shipping it to a custom server, you will get the playwright-cli binary in your bin folder. You just need to run .\bin\playwright-cli.exe install in Windows or ./bin/playwright-cli install in OSX/Linux as part of your deploy script.

I hope all these changes remove some barriers and deploy issues that some users were having.

Bonus track

As we now have the driver in our bin folder, we can use the C# code generator that comes with the CLI.

If you go to the bin folder, you can run this command:

./playwright-cli codegen --target=csharp

And voilà!

I hope you enjoy this new tool. It’s still quite raw. But we’ll get better.

Activity

Repository Stars: 250 (prev 165) +51%
Repository Forks: 26 (prev 14) +85%
Nuget downloads: 2878

Final words

I’m looking forward to getting more feedback. The issues tab in GitHub is open for all of you to share your ideas and thoughts.
Don’t forget to follow me on Twitter @hardkoded to get more updates.

Don’t stop coding!

Previous Reports

Playwright Sharp Monthly Report - October 2020

2020-10-06T00:00:00+00:00

We accomplish two big milestones in September. Microsoft adopted Playwright Sharp and now is part of the Playwright family.
We shipped v0.142.0, which is the first version having full feature match with Playwright!

No v1 yet?

We decided to leave PlaywrightSharp in v0, so we can give you the chance to send us feedback and help us shape the API.
Until we decide to make it v1, the minor version will map to the Playwright version. In this case, v0.142.0 maps to v1.4.2 in Playwright.

Breaking Changes

Now that Playwright Sharp is part of the Playwright family, there must be some consistency between Playwright bindings. But, you shouldn’t feel as if Playwright Sharp was generated by some code conversion tool. Playwright Sharp needs to be a first-class C# library.

During this evaluation, we decided to drop most option classes, like ClickOptions, PdfOptions, etc. We left a few classes related to launch settings, like LaunchOptions. We considered you might want to load those options from a settings file.

Our tools shapes how we code

The tools we use shape how we code. If you use Entity Framework, you will use Linq a lot. If you use Playwright Sharp, we will want you to take advantage of named arguments.

So, if we drop PdfOptions in Page.GetPdfAsync, we woulnd’t like you to do this:

await page.GetPdfAsync(null, 1, true, headerTemplate, "<div>Test footer template</div>", 
true, false, "", null, null, null, new Margin { Bottom = "1in", Top = "2in" }, false);

But this

await page.GetPdfAsync(
  displayHeaderFooter: true,
  headerTemplate: headerTemplate,
  footerTemplate: "<div>Test footer template</div>",
  margin: new Margin { Bottom = "1in", Top = "2in" },
  printBackground: true);

playwright-sharp dotnet tool

One of the weak spots of Playwright Sharp was the need for a await Playwright.InstallAsync(); in runtime. That wasn’t ideal.
Now we can get rid of that line using the new playwright-sharp dotnet tool. It’s as easy as installing the tool and running the install command:

dotnet tool install playwright-sharp-tool -g
playwright-sharp install-browsers

This dotnet tool opens the door to many other CLI features we can implement in the future.

playwrightsharp.dev

Thanks to Meir Blachman we now have a site!
This is still a work in progress, but we started to build the website. You can take a look at the API and a few Examples.

Activity

Repository Stars: 165 (prev 140) +17%
Repository Forks: 14 (prev 10) +40%
Nuget downloads: 550

Final words

Getting close to our first v1 version, I’m looking forward to getting more feedback. The issues tab in GitHub is open for all of you to share your ideas and thoughts.
Don’t forget to follow me on Twitter @hardkoded to get more updates.

Don’t stop coding!

Previous Reports

Playwright Sharp joins the Microsoft family

2020-09-24T00:00:00+00:00

It is my pleasure to announce that today Microsoft forked Playwright Sharp!

Wait, did you give the project away?

No, I didn’t. Because it was never mine.

It’s our project

Playwright Sharp uses the MIT License. That means that Playwright Sharp is mine, and it’s also yours, and it’s also Microsoft’s. It’s ours.

You can do the same! You can fork the project and make it better.

Playwright team rocks!

They could just copy my code and ship it with a different name. But instead, they opened the doors of their team and embraced the Playwright Sharp project.
I think Playwright Sharp fits perfectly in the vision the team has for the product.

But, why?

I think it’s what needs to be done to take this project to the next level. The .NET community needs to grown in their relationship with the open-source. Aaron Stannard explained very well on his post The Next Decade of .NET Open Source.

When a .NET team needs to add a third-party tool to their toolbox, the management evaluates the long term support and the final decision tends to be: “I’d better use a tool from Microsoft than from a random Argentinian guy”.

We developers also have some responsibility. The biggest risk for a .NET developer involved in open-source is Microsoft creating a similar project. And it’s not Microsoft fault at all. But developers would pick Entity Framework over Nhibernate, the default ASP.NET DI over Windsor Castle, etc.
I love how Microsoft embraced open-source and became a big player in the open-source community. But I think the .NET community has a lot to learn yet.

Another reason to move the project is that, despite the relative popularity of Puppeteer-Sharp, I wasn’t able to build a stable team. My hope with this move is to serve way more developers compared to Puppeteer-Sharp and also get more people involved in the project.

Remember, it’s not my project. It’s OURS.

Are you leaving the project?

Hell no! The roadmap will now be aligned with Playwright, which will be great for Playwright Sharp. Arjun Attam is an awesome PM, and I hope he can help me take Playwright-Sharp to the next level.

The future

My dream is to make Playwright-Sharp a first-class automation tool for the .NET community, and there is no better partner than Microsoft to accomplish that.

Give some love!

So, Playwright Sharp has a new home: https://github.com/microsoft/playwright-sharp. Let’s go there and give it some love ⭐️.

Happy automation!
Don’t stop coding!

My programming language is the best!

2020-09-16T00:00:00+00:00

I’ve been porting Puppeteer code (to puppeteer-sharp) from javascript to C# since late 2017 and Playwright code (to playwright-sharp) since early 2020.

One of the things I learned is that programming languages are not about computer instructions, but human interaction.

Migrating code from Javascript/Typescript to C# is not about translating statements. It’s about figuring out how C# developers express what a Javascript developer tried to communicate.

Each programming language has a community, a background, influencers, and frameworks that shape how programs are written.
We can’t deny that javascript was born to solve simple HTML interactions. And we can’t deny that C# was born as a new language to the Visual Basic community.

In the same way that spoken languages follow a community, their habits, and their way of living. Programming languages follow a programming community.

What makes a language good or bad is also biased. We consider French romantic because of French music. We might also consider other languages aggressive because that’s the language of bad guys in Hollywood movies.

In the same way, we might consider some languages cooler than others because of influencers and Twitter hype.

My programming language is the best because it represents my community and how we communicate with each other.

The next time you get in touch with a language you are not familiar with, instead of thinking if it’s bad or good, try to understand from that community and embrace this diversity we have in the industry.

Don’t stop coding!

Playwright Sharp Monthly Report - September 2020

2020-09-08T00:00:00+00:00

Two months passed since our last monthly report back in July. I’m so sorry about that. But, in the past two months, we were able to merge 161 pull requests!

Those 161 PRs took Playwright-Sharp to v0.111.2! You can download this version from Nugget.

A massive change under the hood

Playwright-Sharp now uses a playwright driver to perform most of its operations. That will help Playwright-Sharp to keep Playwright pace, and it will also give Playwright users consistency across different bindings. BTW, Do you need to run Playwright in Python? We now have playwright-python :)

Would I need to install Node.JS to use the new version of Puppeteer-Sharp?

No, the driver will have node.js embedded.

About the version number

The version number might sound quite odd. Let’s unwrap it.
Although this version matches Playwright 1.1.1, I want to leave some room for this API to change. That’s why it’s not v1 yet.

Its minor version is 111 because it matches v1.1.1, and tts revision is 2 because… you know… things can fail.

I believe that the next version will be v1.4 with a stable API.

Breaking changes

The first change you will notice is that we merged all the previous four packages we had (PlaywrightSharp.Abstractions, PlaywrightSharp.Chromium, PlaywrightSharp.Firefox, and PlaywrightSharp.Webkit) into one single PlaywrightSharp package.

There are not many breaking changes in the code. But the way we now install and launch a browser has changed.

Let’s look at this example

static async Task Main(string[] args)
{
    Console.WriteLine("Installing playwright");
    await Playwright.InstallAsync();
    using var playwright = await Playwright.CreateAsync();
    await using var browser = await playwright.Chromium.LaunchAsync(headless: true);

    var page = await browser.NewPageAsync();
    Console.WriteLine("Navigating google");
    await page.GoToAsync("http://www.google.com");

    Console.WriteLine("Generating PDF");
    await page.GetPdfAsync(Path.Combine(Directory.GetCurrentDirectory(), "google.pdf"));

    Console.WriteLine("Export completed");
}

Playwright.InstallAsync will install all the required browsers. It replaces the old BrowserFetcher.

await Playwright.InstallAsync();

As I mentioned before, PlaywrightSharp now relies on the Playwright driver. That’s why we now need to call Playwright.CreateAsync. This method will create a new driver process that Playwright-Sharp will use to interact with the browser.

using var playwright = await Playwright.CreateAsync();

That playwright instance will give us tools to launch different browsers:

await using var browser = await playwright.Chromium.LaunchAsync(headless: true);

From there, everything would look like the code you had before.

What’s next?

I hope we can ship v1.4 during September. That would be our first v1 version. Wish me luck.

Activity

Repository Stars: 140 (prev 117) +19%
Repository Forks: 10 (prev 8) +25%
Nuget downloads: 662

Final words

Don’t stop coding!

Previous Reports

Playwright Sharp Monthly Report - July 2020

2020-07-06T00:00:00+00:00

As promised last month, We shipped PlaywrightSharp.Firefox v0.10! You can read more about this version on my previous post.

Playwright-Sharp as a Playwright client?

We are working with the Playwright team on a Playwright RPC Server.

This Playwright server would package a (Node.JS) playwright instance, exposing its functionality through pipes. Remember I talked about pipes?

If we land with this idea (this is still a proof of concept), we will be able to speed up Playwright-Sharp development, allowing us to work on many other things I have dreamed for this library. I want Playwright-Sharp to be not only a cool library, but the best automation suite for .NET developers.

I’m sharing with you this internals because that’s the purpose of these reports. But Playwright-Sharp wouldn’t feel like just a client. It will be a first-class citizen, and you will be able to use it in the same way you’d use playwright.

So maybe, and this a huge maybe, we would be able to ship a V1 in the next 40 days.

Activity

Repository Stars: 117 (prev 94) +24%
Repository Forks: 8 (prev 7) +14%
Nuget downloads: 274
Contributors: 1

Contributors

Meir Blachman is doing most of the job on the Firefox project, so if you get to use Playwright-Sharp with Firefox, thanks Meir!

Final words

Now that we shipped our first versions, I’m looking forward to getting more feedback. The issues tab in GitHub is open for all of you to share your ideas and thoughts.
Don’t forget to follow me on Twitter @hardkoded to get more updates.

Don’t stop coding!

Previous Reports

PlaywrightSharp v0.10 for Firefox is here!

2020-06-19T00:00:00+00:00

Firefox joined to the PlaywrightSharp family!

What can I do with PlaywrightSharp.Firefox?

You can do lots of things.

Seriously!

You should be able to do almost everything you would do with his older brother PuppeteerSharp or his younger brother PlaywrightSharp.Chromium.
This is how you can take a screenshot in PlaywrightSharp NOW!

var options = new LaunchOptions
{
    Headless = true
};

Console.WriteLine("Downloading Firefox");
var firefox = new FirefoxBrowserType();

await firefox.CreateBrowserFetcher().DownloadAsync();

Console.WriteLine("Navigating google");
await using var browser = await firefox.LaunchAsync(options);
var page = await browser.DefaultContext.NewPageAsync();
await page.GoToAsync("http://www.microsoft.com");

Console.WriteLine("Taking Screenshot");
File.WriteAllBytes(Path.Combine(Directory.GetCurrentDirectory(), "microsoft.png"), await page.ScreenshotAsync());

Console.WriteLine("Export completed");

Is there anything I can’t do?

There are only two features not implemented on PlaywrightSharp.Firefox: PDF generator and Tracing.

Can I use this package in Production?

As I mentioned when we launched Playwrightsharp.Chromium, If you start using PlaywrightSharp now, the API is going to change, guaranteed, but you will jump into a project that will have way more support and new features.

PuppeteerSharp doesn’t support Firefox yet. So I believe PlaywrightSharp.Firefox, even in its 0.10 version, is the best library to automate Firefox in .NET.

Final words

Now that we shipped our first version, I’m looking forward to getting more feedback. The issues tab in GitHub is open for all of you to share your ideas and thoughts.
Don’t forget to follow me on Twitter @hardkoded to get more updates.

Don’t stop coding!

Implementing interprocess communications between .NET and Node.JS

2020-06-08T00:00:00+00:00

Introduction

If you want to implement interprocess communication, you will end up reading about pipes and file descriptors. The problem I found is that .NET does a great job hiding all these concepts from us. I don’t know about you, but I didn’t even know much about these concepts until I needed to implement some interprocess communication.

Motivation

Most headless browsers, e.g. Chromium, have the ability to communicate with a parent process, whether using WebSockets or Pipes.
The problem is that I was never able to implement pipes on Puppeteer-Sharp, and I really want to implement it on Playwright-Sharp.
So let’s see how far are we from getting this done.

Communicating two Node.JS processes

Implementing pipes in Node.JS it’s pretty simple and straight forward.
Let’s say I have a parent and a child app. When the parent app creates the child app process, it will be able to set up the child’s stdin (File descriptor 0), stdout (File descriptor 1) and stderr (File descriptor 0), but not only that, it will also be able to create more file descriptors, which can be used as an extra set of pipes.

const server = childProcess.spawn(
  'node',
  ['../child/index.js'],
  {
    stdio : ['inherit', 'inherit', 'inherit', 'pipe', 'pipe']
  }
);

In this call, we are not only setting up stdin, stdout, and stderr, but we are also creating two pipes using the file descriptor 3 and file descriptor 4.

Let’s create two small scripts to test this. We will write a parent app which will read an input from the terminal, it will send it to the child app, and the child app will echo it.

The parent app would look something like this:

const readline = require('readline');
const childProcess = require('child_process');

// Create child process
const server = childProcess.spawn(
  'node',
  ['../child/index.js'],
  {
    stdio : ['inherit', 'inherit', 'inherit', 'pipe', 'pipe']
  }
);

// We will use the File descriptor 3 as a writer and the File descriptor 4 as a reader.
const reader = server.stdio[4];
const writer = server.stdio[3]; 

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

// When we get data on the reader we print it
reader.on('data', data => console.log(data.toString()));

// We are going to send a message to the child
var waitForMessage = function () {
  rl.question('', (message) => {
  
    if(message === 'exit') {
      rl.close();
    }
    writer.write(message + '\n');
    waitForMessage();
  });
};

waitForMessage(); 

The child app will be super simple:

const readline = require('readline');
const fs = require('fs');

// We will create an stream reader from the file descriptor 3
const reader = fs.createReadStream(null, {fd: 3});

// And a writer from the file descriptor 4
const writer = fs.createWriteStream(null, {fd: 4});

// When we get a message on the reader we echo it in the writer
reader.on('data', data => writer.write('echo: ' + data + '\n'));

// This is how a .NET developer leaves an app open in Node.JS
setInterval(()=> {}, 1000 * 60 * 60);

So far, so good. It works

Now, let’s get to the important part. Can I connect a .NET app there?
.
.
.
.
No, you can’t. It’s not possible to add more streams on a Process instance in C#. You will find a way better explanation here.

So, our next and final test would be trying to create a .NET app, create new pipes in there, and then passing those file descriptors as an argument to the child app.

The child app would be quite simple. We replace the hardkoded descriptors 3 and 4 with command line arguments:

const readline = require('readline');
const fs = require('fs');
const reader = fs.createReadStream(null, {fd: process.argv[2]});
const writer = fs.createWriteStream(null, {fd: process.argv[3]});

reader.on('data', data => writer.write('echo: ' + data + '\n'));


setInterval(()=> {}, 1000 * 60 * 60);

Now, let’s go to the .NET world. We know there is something called Anonimous Pipes. Let’s see if that works:

static async Task Main(string[] args)
{
    // We are going to create two pipes, one writer and one reader.
    using var pipeWriter = new AnonymousPipeServerStream(PipeDirection.Out, HandleInheritability.Inheritable);
    using var pipeReader = new AnonymousPipeServerStream(PipeDirection.In, HandleInheritability.Inheritable);

    // We create a child process passing the pipes handles as string.
    Process client = new Process();

    client.StartInfo.FileName = "node";
    client.StartInfo.Arguments = "../../../../Childwitharguments/index.js " + pipeWriter.GetClientHandleAsString() + " " + pipeReader.GetClientHandleAsString();
    client.StartInfo.UseShellExecute = false;
    client.Start();
   
    // If microsoft docs tells me to call this method I will.
    pipeWriter.DisposeLocalCopyOfClientHandle();
    pipeReader.DisposeLocalCopyOfClientHandle();

    // We start listening to messages
    _ = StartReadingAsync(pipeReader);

    // We create a stream writer, and we will write messages on that stream.
    using var sw = new StreamWriter(pipeWriter)
    {
        AutoFlush = true
    };

    string message = Console.ReadLine();

    while (message != "exit")
    {
        await sw.WriteAsync(message);
        message = Console.ReadLine();
    }

    client.Close();
}

private static async Task StartReadingAsync(AnonymousPipeServerStream pipeReader)
{
    try
    {
        StreamReader sr = new StreamReader(pipeReader);
        
        // This method should get a CancellationToken so we use that instead of a while true.
        // But this will work now.
        while (true)
        {
            var message = await sr.ReadLineAsync();

            if (message != null)
            {
                Console.WriteLine(message);
            }
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex);
    }
}

Final Words

It was so cool to find that we can implement this kind of solution between both frameworks. I know that implementing pipes is not something most of us need in our daily job, but you know, maybe someday you will need to connect to a browser using these pipes 😉.

If you want to take a look at the source code, you can find the repository on Github.

Don’t stop coding!